>Hi all,
>This one is from a newsgroup and I promised to have your ideas.
>***************
>* Start
>***************
>
>Sorry about posting to so many newsgroups. I need an answer quickly. If my topic does not fit your newsgroup, please accept my apology.
>
>I don't know enough of the technical terms because I am not a programmer, nor do I know if it would make sense to someone
>somewhere else.... the cost is enormous ($$ and time)
>
>We are running
>
>MS Visual Fox 3.0b
>MS Windows NT 4.0 Workstation
>Novell IntraNetware 4.11
>
>The nature of the problem is as follows:
>
>A user browses a Fox table and makes (mostly manual) many changes to a
>field. These changes are viewed on another machine by a different user and verified. The file is closed. The file is opened the next day, sometimes again later the same day. Some of the changes that were made reverted back to the previous state. Some of the changes that were made held and are still okay. The end result is, a lot of changes were lost in an inconsistent way.
>
>Other facts:
>
>The tables we use are typically 5-25 fields, and anywhere from 1,000 to 50,000 records. There does not appear to be a pattern to what reverts back to a previous state. It is not time based. For example, it is not a matter of the last 15 minutes of changes being lost. The changes that are lost are throughout the file. They are specific and definite cases. It has happened with one user and with multi-users in a table. It is not connected to a server (or a machine) crash (though that does cause other problems). Both the file and the Fox config file are run off the Novell server. Fox is ran from C drive. We have tried running Fox from the server as well and the same thing seems to happen that way as well. It happens rarely, but there is no doubt that it does occur. The damage is extensive. There seems to be no
>viruses on the system. It is not connected to a specific user or machine.
>
>Some thoughts:
>Since changes made in the file by one user are seen by another user (after a screen refresh), the data must be correct in the buffer(s). It is almost as if the data is either not getting written entirely to the disk consistently, or somehow Novell is getting the timed backup versions of the file confused.
>Neither postulation makes sense. Somehow it seems connected to cacheing, the buffers, and writing to the disk…?
>
>Can anyone help with this problem or offer any ideas or suggestions? I'm open for anything. This does not happen a lot but does happen occasionally.
>We work with many different tables and databases from clients each week.
>Thank you ahead of time for your help.
>
>Michael Todd
>Network Administrator
>Paragon Company
>mike.todd@paragonco.com
>
>***************
>* End
>***************
>Cetin


Sounds like classic data loss issues. The same things apply:

1. Make sure the users are exiting the program, not just shuttng off the computer.
2. Issue FLUSH to make sure the local PCs buffers are flushed.
3. Turn off all write cache on the server's disk controller.