Another User has exclusive access to report file

We have a site that suddenly the statement run began halting with 'Another user has exclusive access to the report' and points to the path and frx part of the statement. Retry doesn't work and when click cancel the frx part of the design has been removed and we put it back and they carry on. This issue also arises in Repeat Invoicing within SOP

As a result they have begun breaking things down into smaller batches but the issue still arises. It seemed to be mainly the one user having issue but she is the one that mainly runs the procedures however this user and another user have now started getting issue raising an invoice or credit note within SOP Processing, again pointing to the relevant design and then removing the frx part. Here we see an extra message of 'Failed creating PDF would you like to Retry' but the 'Another user has exclusive access' to the report message is in the background. Last time this happened around 15 credit notes had been raised and then got this

Our logic is AV but we have been assured that AV settings are correct, they did say a couple of weeks ago they weren't quite right and we thought we'd cracked it but it seems to be worse. There is an internal IT department who do not have full access and definitely not to AV, an external department for the group controls this

They don't appear to be getting file accessing errors whilst processing, although after AV changes period end was running for an hour on server instead of 10 minutes then crashed, restore took 2 hours, UDS crashed with file accessing errors (stopping in different places), swapped to a client then all worked perfectly from a client

Has anyone else had similar problem, did it turn out to be AV or any other suggestions would be much appreciated

Kerry

Find more posts tagged with

Pegasus - Partner General Discussions

Accepted answers

All comments

unknown

which AV is it?

kerryh

It's Microsoft Defender on the local machines. The internal IT think McAfee on the Server but are double checking. We have given the paths for installation folders for server and clients and that opera.exe to be set as a trusted file

alan-bourke

Any time I have seen FRX and FRT files being interfered with or deleted it has been AV.

fzw

I had a site recently with Windows Defender, the IT refused to accept that the exclusions needed to be set up on the client and server. In the end the customer told them to remove it and put in ESET (the same as the parent company). So far so good.

If it happens every time they run statements I would run ProMon along side as this will tell you what is deleting the file. I would have done this on my site however the files were only being deleted sporadically maybe 2 or 3 times a week.

Good Luck

Felicity

colin-avey

I agree, AV is generally involved in the equation somewhere, and usually the problem. The site we have/had the biggest issue with uses Webroot, also 50 users and several companies

We found a couple of things helped mitigate the problem. Most if not all of this has been sorted by Pegasus in more recent versions by changing the way unique temporary report files are created in .Reports.

If you are getting old style unique files (_6KP0O3E4P.frx & .frt) left in the reports folder, it is possibly an indicator that report hasn't been updated. The newer style contain the user ID in the file name.

We found it was possible for two users to try and create the same temporary report name, particularly in SOP batch processing (2 or more users doing batches in different companies at the same time). To be clear, SOP Batch processing has since been updated.

We also found for some regularly used reports it was worth creating user specific copies (sqslstat_alice & sqslstat_bob etc)

Colin

unknown

We have a customer having similar issues, what environment is Opera installed on?

kerryh

Windows Server 2019 Standard Version 1809 (Virtual Server), clients are on Windows 10

0911060553270289.pdf

claire-craig

Hi Kerry, we also have a site which use Microsoft Defender which was deleting the report frt/frx files.
Our solution was to ensure that the sub-folder "Reports" of the O3 Server VFP Static and Dynamic share got added to the exclusions which made a huge difference - as a belt and braces we also added in the file extension types.
Regards
Claire

emaniega

Hi Kerry,

We are experiencing this issue with two sites as well. We have made sure that the AV has the appropriate exclusions and no joy. They are using windows defender and Sophos. We are convinced it is AV or environment. but just can't get to the bottom of it. The closest we have got is we found in the error logs on the server that the user ID of "system" was accessing the file which had been deleted and then stating further down in the error log that windows defender advanced protection was accessing the file. Maybe worth getting the error logs checked out to see if there are any clues in there.

We are no further forward with this theory right now as the IT company say this is not the cause, but we are not convinced.

Thanks

ianc

Hi
I know this is an old thread, but we have had similar issues across a broad range of reports. Issues are intermittent, but most commonly used reports (orders, deliveries, invoices) appear to break most often.

For us, this started after a Windows Update on the server in July. We don't do their IT. We've excluded all Opera folders from AV.

What appears to happen is that Opera renames the .frx to 9999999.tmp for some reason, then renames it back later. If this fails, the reports isn't there next time someone tries to use it.

For batch processes, this can then lead to spurious errors depending on which process is being run. The errors seem like they're an issue within the report, but they haven't changed, so they can't be at fault.

I don't understand why the .frx file is being renamed. Our current workaround is to give the user a "fix" program which copies any affected reports back again. We're left with many .tmp files in the Reports Folder.

I've logged with Pegasus to try and understand what's happening at the point of error, but keep getting pushed away.

If this is some kind of clash between VFP and the Windows Update, then I think it will become more common as Windows Updates are applied.

The customer has been updated to the latest version of Opera, just to see if that would fix it. They've also re-cabled and audited their network to rule that out.

Is anyone else still seeing similar issues?

Thanks

Ian

Expense_Management Roadmap - October 2020.pdf

Steve Loader

Hi Ian,

These issues are almost always down to AV (despite having excluded the necessary Pegasus folders).

What AV is your customer running?

Kind regards

Steve

dEPM-625-Using dEPM in ION Workflows.mp4

ianc

Sentinel

tcyprys

Hi Ian

I am just dealing with one now and in our testing of a laptop with all AV removed (PC and Server - I know that isn't always possible to test in this way), the issue doesn't occur. This is ESET AV.

There was, interestingly, a printer that was locally added to one of the PC's that made the issue occur more frequently... not sure how that affected the issue but it definitely helped when we removed it.

I have asked them to add the AV back in with usual exclusions but also to exclude(whitelist?) the FRX/FRT type files.

Will let you know if this is successful or if something else crops up.

Regards

Tony

ianc

Thanks, Tony.

the printer one is an interesting one. I feel like this is a "percentage" thing and different factors increase the chance of this happening, but nothing guarantees a fail.

We don't do the IT on this site, so are relying on their IT company to do what we ask.

I'd be interested to know, though, why Opera renames .frx to .tmp - I can't think of a good reason...

Ian

0911060553270289.pdf

Copyright © 2025 Infor. All rights reserved.