>>There could be another source of the problem - network. 2 years ago, when working with VFP files through network, I often got SCX/PJX files corrupted when network fail or computer fail. There are options in the network and NT that allow to make buffering in the network minimum, so data lose is minimum. Well, this decrease speed of the network, but increase the reliability.
>
>But then these files are tables as well, right? Seems to be there are several ways a file can be open (with different options), and while we're safe with tables now - haven't seen a corrupted .dbf/cdx/fpt on W2k at all - it seems other types of file open are not as safe.
>

My guess is that network buffering issue is very limited in the time, in other words, need to catch the moment very precisiously when to switch off the power to catch the moment when data updated from VFP and not saved because buffering in the network and at the server machine.

>As for the original problem, I was thinking of a different solution: writing measurement results into local tables, and having them copied to the server periodically. A routine running on the server could merge them as they come, working with its local copies. Each workstation would have to have a prefix on the primary key. I've had this with the same type of app (weighing stations) where the workstations were miles away from each other and the central unit. Sometimes the files were coming in by modem, sometimes by floppy, but the general replication scheme worked, based on each station's prefix on primary keys.


VERY nice solution, though some data still required to be as latest as possible (real-time). In such case it will not work and other solutions are required, sch as mirror data (writing into the 2 databases) that will assure at least one of the database after power off contains correct record.