>>This problem is affecting a couple of us in when we open a VFP report (frx) it takes forever to open. And same with when you close it. And the files are local on my laptop. Not on a fileserver at all.
>>
>>I copied the files down to my home PC and I can open and close them as normal.
>>
>>I've deleted the Foxuser.dbf. I've connected to work with the VPN where normally I don't have to unless I need a shared resource. I had this problem before because I hadn't been on the VPN for days and I think the local Group Policy rules couldn't update. So, today connected to VPN and after doing a gpupdate /force and reboot still have the same problem.
>>
>>Opened the FRX as a table and saw nothing strange and no image files being linked.
>>
>>Checked the virus scanner (Symantec) logs and saw nothing. Can't turn off Virus scanning because it's corporate controlled.
>>
>>Examined event viewer, reliability tool, and what else? Oh, process monitor to see what's going on under the hood.
>>
>>I'm not sure if customers are having a problem running reports or not.
>>
>>Any ideas? We're stuck. TIA
>
>Are you running VFP in a VM, a container, or on bare metal?
>
>Besides antivirus, do you have any other 3rd-party system utilities running such as "real-time" or "continuous" backup, Windows File History etc.?
>
>It's too bad you can't turn off Symantec for test purposes. With managed AV usually the admin can temporarily grant permission for end users to disable the AV on their endpoint, can you take advantage of that? On the other hand maybe you can "rule it out" if there are other computers running the same AV which don't have this issue.
>
>ISTR a long time ago having report performance issues where they had been converted (?) from DOS to Windows. I deleted the DOS-related rows in the FRX and PACKed it, as I recall it went back to "normal". There may have been a bunch of deleted rows in the table in addition to the DOS ones.
>
>A long shot, but ISTR some VFP operations can perform erratically on systems with lots of free RAM. You can test for this by setting SYS( 3050 ) to slightly less than 512MB or 256MB (say, 511MB or 255MB). Long-time users may recall the original release of VFP 3 would not run reliably (or at all (?)) on a system with 512MB or more RAM, MS had to release an update to address that issue.
>
>Another long shot - do you have any slow storage attached to your system (e.g. USB stick), which may be on the VFP PATH or otherwise touched by it? If so try removing any such storage.
>
>Not sure what you mean by "reliability tool" but some general things to look at:
>- CHKDSK to see if there's anything funky with your storage system
>- From an elevated CMD prompt, run the System File Checker: sfc /scannow
>- ISTR you have RAID1 volume(s). You could check for any issues with that
>
>If you've used Process Monitor:
>- Where's the bottleneck: disk, memory, CPU or network? Resource monitor...Disk tab is a useful way to keep an eye on disk performance, especially Disk Queue Length in the Storage section
>- Which process(es) are performing poorly?
>
>All assuming you're not extremely low on free RAM, disk space or any other critical resource.

I wonder if the VFP coverage profiler could help find the bottleneck ???