Joe,

I definitely can sympathize with your problem. Tracking down intermitent corruption is quite tedious.

Here are a few questions that I would be asking if I were in your situation...

Are these servers being used for other applications as well that could compete for resources with your VFP tables? Do the servers use RAID or is access dependent on a single harddrive? What is the overall network load like? Do people experience network slowdown's or any problems copying files over the network aside from the FoxPro app? Do you ever get any 'Can't read file' errors in FoxPro even if it doesn't end up corrupting the table?


Can all machines see each other on the network quickly? If you do a 'find computer' are there some machines that show up slow or not at all? If so, this could mean the network has high load or 'brown outs' in it.

Also, no client machine using VFP should be without an APC battery backup. This is a sure way to corrupt tables, indexes, and everything else.

Is it typically the same index files? If so, you may try wrapping anything that would write to the table in transactions. Maybe try using INSERT's rather than APPEND BLANKS and a series of replaces. Sometimes just by choosing a different syntax or wrapping in transactions can change reliability.

I've also had some success in improving reliability by pulling data from tables into cursors and then closing the main table.

Example:

SELECT * from contacts where contactid = vp_contactid INTO CURSOR Name_cursor
SELECT contacts
USE

Instead of using the table to build the form, only open the table long enough to populate a cursor, then close the table. With the table closed there is no possibility it can be corrupted after the form has been launched. If data needs to be updated, then you open the table just to do that.

If there are forms that are keeping files open on the server, the longer they are open the greater the chance that something could go wrong. This may not work for your application but it can't hurt to start looking for ways to minimize the number of open tables and how long they are open.

Anything you can do to keep the main tables closed and only open them for updating will improve your reliability.

At one location I was had some workstations with NIC cards that appeared to work fine but would sometimes corrupt VFP indexes. Once I changed out the NIC's then all the problems magically disappeared.

Hope this helps you some, I feel your pain!

Greg


>Hi Greg.. each of the 20 is a separate network at an individual plant site (located around the world). Some networks are smaller some are larger... just about all of them experience 1705s... some a quite a bit more than others. I have no influence on network decision at all, I can only control the source code and report things I learn to the other departments (such as server department, network department) and even they dont have enough clout to change settings :(
>
>thanks for the tippers!
>
>>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")