Calvin,

This has some of the same characteristics as MSKB #Q293638.

One recommendation tht came in that wa said the greatly reduce the frequency was to put 2 dummy fields, one numeric and on character 10, at the very start of each record.

Another recommendation that I have seen often, and believe it to be a good one too, is to endure that "OPLOCKS" is turned OFF.

good luck


>I have one user on a relatively large network (30+ workstations, 5 or 6 of which are using my app) using a Linux server and WinXP Pro workstations that is having a data issue on busy days. Each user has a local copy of the exe and is using data off the server. I am checking the physical size of a file versus the logical size ((rec no * num recs) + header size) before any crucial operation is performed. Multiple times during the day this check reports that the physical size of a file is greater than its logical size. They then have to run a utility that fixes this problem. The result is that one record is lost. This only happens on busy days and I need to find out what is causing it and how to fix it. I have had this occur before in isolated circumstances for other users. This is different because it always happens whenever they get busy. However, even on busy days this app would not be considered to be data intensive. Inserts into the table that is getting out of whack are inside a
>transaction that is flushed when complete. Can anyone point out a starting point for an investigation.