The part of single user having no speed degradation points to some oplocks mixup. OTOH XP as server OS should guard against all SMB related errors.
If you have the old registry backed up, compare before and after the critical time, with double-checking Oplocks and SMB settings.
From a pure reflex I'd also check the mapping, looking through hosts or similar misdirections, even if I have no clear hypothesis to check, but that probably is my problem ;-)

You mentioned checking temp location. Perhaps add checking that via logging, somewhere between double- and triplechecking ;-)

(will mention logging of set exclusive and similar sets only in this bracket as your error description and already checked steps indicate you have already guarded against it, but logging of cursors/[temp] tables via dbf(), isexclusive() and so on is much better than debugging most of the times in such problems.)

HTH

thomas

>Hi All,
>VFP 9/SP2 app using VFP for the database engine and running the executable from the workstations. Workstations have a local app folder with a mapped drive to a shared folder on the server where the data resides:
>
>Server is XP Pro/SP3
>Workstations are XP and Win 7 Pro.
>No windows updates on the workstations or the server for months prior to 12/31/2014.
>No change to my app or the database since September 2014.
>Plenty of disk space on server and on workstations.
>
>ISSUE: As of 12/31/2014, my app is experiencing horribly slow access to the data.
>
>Live environment (workstation’s X drive):
>As described above
>
>Test environment (workstation’s Y drive):
>Copy of live environment to a different folder on the same HDD on the same server and also shared.
>Map an additional drive letter to the test environment on the server.
>
>Both environments are the same with the same data.
>Bill_Codes table contains 12 records.
>Bill_Code_Hist contains 54K records.
>
>From a workstation using foxpro command window:
>Set exclusive off
>open database X:\data\inmatetrustfund.dbc
>select * from inmatetrustfund!bill_code_hist inner join inmatetrustfund!bill_codes on bill_code_hist.cbill_codes_id=bill_codes.cid into cursor lcresult
>-- takes 101.48 seconds --
>close databases all
>open database Y:\data\inmatetrustfund.dbc
>select * from inmatetrustfund!bill_code_hist inner join inmatetrustfund!bill_codes on bill_code_hist.cbill_codes_id=bill_codes.cid into cursor lcresult
>-- takes 5.34 seconds --
>
>The database has approx. 100 tables. I get similar results regardless which table(s) are queried.
>
>I should mention, running my application has similar results meaning it takes 20 times longer to do operation A in the live environment versus the test environment.
>
>I also conducted a test copying large files. There is no difference simply copying or moving files between the workstation and the server regardless whether performed on the X or Y drives.
>
>Perhaps the most important fact: As long as only 1 workstation has the database open, there is NO difference between the live and test environments. It is ONLY when another user opens the same database as I am testing against, that the slowness occurs.
>
>This app has been running well for over 10 years. This only started 12/31/2014 and has been persistent since.
>
>I have of course reindexed all tables and have looked for any sign of bad data and can find none.
>
>Thanks for any help,
>
>John Cook