Joe,

If you are getting lots of corruption I would suspect that network conditions or network load may also be part of the problem. Sometimes adding just one more server or one more network connection is enough to impact reliability. In my experience, I've found that the possibility of data corruption goes up substantially as a network grows.

In the past I've used terminal services in environments that start getting too large for FoxPro databases. This keeps the table from being opened up over the network. You also want to make sure all you users document every lockup or crash they have on their workstations.

I would suspect that with 20 NT4 servers that you have a very large network and this could be contributing to reliability issues.

Greg

>Alright! I talked our department that manages the server into disabling OpLock on our NT4 server, and the 1705's have almost completely disappeared! Now I have to talk to them into doing it to the other 20 NT4 servers we have running this app :( That will take a long long time. I wish Microsoft had a more definitive document that says it must be done for FoxPro to run decently.
>
>However, 1705's still exist on this server, like once a week. (As opposed to every day it used to be before we turned off OpLock)
>
>Is there another 'write-cache' something that needs to be disabled on the server (that is not OpLock setting) ?? Or now it is probably Client settings? We have windows 95, 98, and 2000 running against this database. They have virus checking software, but they are all set not to scan the network, so the database should be OK there. However, we have not changed any OpLock settings on any of these clients... do we need to?
>
>If so, I don't know if I can sell that to the department that manages the clients unless I have good proof. Oh too many departments!
>
>THANKS AGAIN!!!!!!!!!!!!!!!!!!!!!!!!
>
>
>
>>If you've ruled out all of the other possibilities mentioned already (write-cache, opportunistic locking, client settings, etc) then I would definitely verify the set exclusive setting on each client as well as the anti-virus settings on the server and the clients. Is it possible the tables are being scanned or quaranteened or locked for scanning? Also, can you post the code just before the errors occur (to rule it out)?
>>
>>
>>>Hi there, I am not having much luck.
>>>
>>>It seems that SOMETHING is locking either the dbf, or the cdx, or the fpt (one at a time) and then all the users cant access that table and they start to create these 1705, 111, and 41 errors.
>>>
>>>Could it be client settings? Something to do with the network? I don't think its the server... we have identical server at another plant running the same exact software, and they do not have this problem.
>>>
>>>THANKS FOR YOUR HELP
>>>
>>>
>>>>Definitely. Also turn off any power saving on the network cards on the server and the workstations. If you do a search on the UT you will find other recommendations as well that are a very good idea to consider and possibly implement.
>>>>
>>>>>Hi again, thanks for your last email!
>>>>>Do you think its a good idea to disable write-cache on our NT4 server that runs our fox apps?
>>>>>
>>>>>Our server dude says, "Cache on the server's logical drive is in write-back mode. This is the default setting and I am not sure how changing it would affect the server, we try not to mess with that."
>>>>>
>>>>>THANKS AGAIN!
>>>>>Seth
>>>>>
>>>>>
>>>>>>Do you have SP3 installed? Is write-cache on the server's hard disks disabled? If not, I've seen some corruption of tables occur...
>>>>>>
>>>>>>>Hello Everybody,
>>>>>>>After we move to Windows 2000 server we've being having a lot of data corruption, indexes get corrupted, containers get corrupted, I don't know what to do, has anybody experience this often in VFP 7 ???, is there any software that might help, I have FoxFix, and it works good half of the time, but I need something better. Any Ideas?
>>>>>>>
>>>>>>>THIS.Thanks("In advance")