Any .FRX report file being renamed

Hi, we have a 2 user Opera site, linked to a server. All of a sudden on the 17th Nov, one user reported issues where her import routine wouldnt work. After much poking about, we learned that the day before, they had Webroot Secure Anywhere installed. We then asked them to exclude Opera from this AV on the users machine, from the usual folders - made no difference

They then suggested disabling it completely. This allowed the import to work, but when it got to the point of producing the audit report, it crashed saying it had a problem with the report file. When you browse to the report folder using windows explorer, it has renamed the .FRX to something completely different e.g 34793749837.TMP - so you can instantly see why the report isnt being produced.

We then discovered that this is happening to ANY report in Opera, e.g if you ran a sales invs & crs report, it would do the same, crash & rename the .FRX

So we were just wondering if anyone has come across Opera renaming any .FRX file when a report is run?

Many thanks

Find more posts tagged with

Comments

alan-bourke

Opera does do this to facilitate multi-user printing, and because it has to programmatically manipulate the report header. So when the Publisher is used to produce a report (either with the standard Printer/File/Spool/Email UI, or silently as in the case of the Importer) it copies the layout files, does what it needs to do to the copied frx/FRT and prints using the copies. When finished it then deletes them.

We had a couple of sites over the last few years who would have an FRT/FRX mysteriously disappear on occasion. Always turned out to be the AV. So I think you need to exclude either the reports folder or the FRX and FRT extensions from realtime scanning.

Legacy Contributor

Interesting background info there Alan. We've always found it to be AV related too. James, have you ensured AV exclusions are in place on server too?

Legacy Contributor

Hi guys, many thanks for the responses, much appreciated. Weve basically had to go on what their IT people have said (and when we've spoken to them, they havent sounded that clued up, to put it politely) They confirmed that all Pegasus folders are being excluded on the server, but like I say its their word that weve to take & we dont have direct access to their server to have a poke about. Interesting, that the other machine works fine, its just this one machine. So if it was server based, youd expect the other machine to exhibit the same problem? Anyhow, theyve agreed to get a new machine. The problem being then, if they reinstall the same AV! Ill keep you posted if the same thing happens. Once again, many thanks

alan-bourke

The name Webroot rang a bell, and it turns out that they are unusual in that at least up until fairly recently they did not allow locations to be excluded from scanning, in a 'we know best' attitude. Which is great until it starts deleting legimitate EXEs generated by a software developer as per this thread:

community.webroot.com/.../205312

joe_cancglin

Hi,
We are noticing an increase in customer sites complaining about there document design layouts not working or disappearing.
Usually we would put it down to AV exclusions but two sites in particular we handle there IT and software requirements as well as fully support.
Any suggestions would be appreciated.
Thanks
James

alan-bourke

I have seen the Windows Indexing Service cause problems with printing also, it seems to be configured to index nearly everything on the server on recent 'small business' editions of Windows Server. Although it was more a 'file accessed denied' problem the attached might help in tracking down what the issue actually is.

alan-bourke

Sorry attached.

richardd

Hi James, we have the same issue at a couple of sites too and we also manage their AV so know the folders are excluded. Are your sites running on TS servers by any chance?. 2 of our bigger sites are running on TS and the SOP documents reports go missing on a regular basis.

richardd

Thanks Alan, I will look at indexing too.

john-patterson

Hi,
This issue relates to the *.frx file being renamed to [something].tmp

My understanding is: while printing, Opera will create a temporary file. This file is a new file: pub*.* and not a change of the existing report files. The *.frx and *.frt files should be left in tack at this stage; waiting for the next user to print - another pub file is created... etc, etc?

AV exclusion are definitely in place on the calls that I have open for this. We look after their network.

Regards
John

alan-bourke

Yes when reporting via Publisher Opera makes temporary copies of the FRX/FRT in the user's temp location, amends those (the TAG and EXPR fields in the first record) and then reports using those. They should then be deleted after the Publisher is finished.

Is the AV exclusion ignoring all files in %programdata%pegasusclient vfp emp ?

Also even if AV is ostensibly disabled from on-access scanning there is still very likely a filter driver in place that might access the file - would it be possible on one PC to remove any third-party AV client completely and use Microsoft Security Essentials for a few days to see what happens?

john-patterson

Thanks Alan, so far, on one site, the Windows Indexing was on, now turned off and is holding, but it's early days.

There was a spelling mistake on another site's AV exclusion to programdata, which has now been sorted. Fingers crossed for this one, too.

Thanks again
John

Copyright © 2025 Infor. All rights reserved.