Here's my usual list of suspects, some of which are already mentioned above:
Does the XP client have read/write/modify rights to those network tables? From that XP, Go into Start/Explore and right-click on some of the problem tables, select Properties, then Security.
Shared folders: Remember, when a directory or folder is shared, you have to go into the Permission button to enable writing. The default is to only allow reading. Make sure your user or his group is listed there with rights to read/write/modify.
Folder and/or file security rights: Are these different users on the different computers? If so, have one of the users who you know it works on his computer go and log in to the problem XP.
I wonder which files it's having problems with, are they the same ones all the time, or random ones? Are the files on the server or on the local computer? If it's on the server, verify the user or his group does have read/write/modify rights on that table/memo/indexes or folder(s). If it's a work or temp file on the local computer, then it could be a rights issue of the person logged onto the XP computer. If the user doesn't have Administrator rights, XP will not let them write to the
root directory of the computer. Does your program write tables or other files to the C:\ root directory?
Another idea is that something about the table has changed and the program tries to change the table but can't because it's been opened with SHARED or maybe NOUPDATE. Was the CDX (table's compound index) changed by another database language so that FoxPro wants to rebuild the index? It needs exclusive access to do that. Or maybe the language driver is different?
Opportunistic Locking on the XP can affect this. If so, add 2 new entries in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableOplocks REG_DWORD value = 0
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled REG_DWORD value = 1
There's also a bug with XP clients that was fixed in XP Service Pack 1. Are you up-to-date on security updates?
Physical problems: Sometime a faulty NIC (network interface card) or network cable is at fault but that's pretty rare.
Computers faster than 3.0 GHz: Recently some users have reported that they've had problems with FoxPro either at or exceeding that speed. Probably some internal timers were designed long ago not expecting a computer to go that fast. (There was a FoxPro fix for computers going faster than 300MHz many years ago, but I wonder if that "fix" only bumped the limit from 0.3 GHz to 3.0 GHz...) Search the forum for these reports. Very unlikely to ever see a fix this time around.
Hard to really say what your fix will be, but these are some ideas to check out. When you do get it fixed, let us know what did it.
Windows NT, 2000, 2003 and XP all emulate DOS, not natively as the older Windows do, and as you now know, it does not emulate perfectly.
Even if you don't figure out the exact cause of your problems now, you can continue to use Windows 98se or Millennium. Long term, I'd suggest you decide to upgrade to Visual FoxPro 9.0 which just had Service Pack 1 beta released. All you need is to buy one copy per developer or whoever compiles the code and you can provide unlimited compiled EXEs or DLLs for all your other users. (The VFP development program must be installed on a Windows 2000, XP or newer computer but any Windows 98 or newer computer can run the compiled applications.) If your programs are not too complicated, a simple port can finally move you out of the DOS world. There are 5 VFP forums here:
