>HI Everyone!
>
>I have a problem that I'm dealing with that I'm sure others have wrestled with. Recently we moved our VFP application from a Windows 2003 server to a Windows 2008 R2 server and have started having issues with DBF file operations taking a long time to process. For example in one place it was just doing a SKIP through a DBF with about 20k of records and the coverage profiler was saying it took 3 minutes. But in other places it seems to be working fine. At other times it will open a table Read Only even though it's not coded to. Or we will get file locking errors. At times there can be up to 90 users in the system that are hitting these tables so we think this might be some of this issues, but then in other places no one is in the system and it will take forever to run a process. This is a legacy app that does old time methodology of table locking. No table buffering is being used either.
>
>Has anyone had any experience with Windows 2008 issues? I know there are posts about SMB2 and Optlocks but we don't think that applies here because this application is not run over a network, but rather users remote in via Terminal Services and run it right on that server. MS even says on their website that this SMB2 doesn't apply when running on TS. However we did try disabling these at one point and it brought the system to a crawl. Also the vfp exes are running in Windows 2003 emulation mode and while that seems to have helped a little, we still are having the issues.
>
>So is there anything else anyone knows of to make VFP and 2008 play nicer together? Also, we haven't done any testing on 2012 Server but are wondering if it might be better in this regard.
>
>Any guru help would be greatly appreciated!!!!

If I understand correctly you have a Server 2008 machine running the Terminal Services/Remote Desktop Services role, with up to 90 simultaneous sessions active. Also you have the shared VFP data files located on a local drive on that same server.

Some thoughts:

1. Antivirus - if an AV package is active on that server, see if you can temporarily disable real-time scanning for test purposes, or at least exclude the VFP data tables plus every user's temp files folder

2. That's quite a few TS sessions. Is it possible some of those sessions are doing something CPU- or disk-intensive, so some VFP sessions are getting starved for resources? To get a handle on this you may need to monitor CPU and RAM usage, plus relevant disk counters such as Average Disk Queue Length

3. If you have a lot of simultaneous sessions sharing VFP data tables, you will need to ensure your table locking mechanisms are bulletproof. For example in VFP9 SET TABLEVALIDATE may lock a table header during opening or append, depending on its setting. You will also need to guard against more conventional problems such as deadlocks e.g. http://msdn.microsoft.com/en-us/library/b6axebf1%28v=vs.80%29.aspx . You'll need to avoid constructs like

DO WHILE NOT RLOCK( TableAlias )

ENDDO

as well as inappropriate values for SET REPROCESS etc. Sometimes with a small number of light simultaneous users one can get away with holes in lock strategies because they almost never get hit. But problems will likely appear with a large number of active users.

4. If the Terminal Server is a cluster or farm, rather than a single server there may be best practices that should be followed for general cluster operation, and specifically for supporting file-server databases such as VFP or MS Access

5. What is the exact type of storage on which the VFP tables reside? With some larger servers or environments it may not be conventional disk(s) in the server chassis, it may be a SAN, NAS or external array accessed via Fibre Channel, iSCSI etc. These devices are usually configured so they appear to be "local" e.g. they can be assigned a drive letter. Nonetheless most of these devices are not running Windows, they run a different OS and emulate Windows file services. Multi-user VFP apps are a demanding test of Windows file services. If the external storage emulation is not perfect you might see the kinds of problems you're seeing. You'd need to talk to the sysadmin and see if there are any configurable parameters that might trade reliability for performance, and if so see if they can be tuned to favour reliability.