Dragan --

Well, ain't that interesting -- yup, this isn't the time for interesting. I would have thought that the easiest thing (and least errorprone) would be to open a file, append a record, and close it.

From what you're suggesting, it does not appear that you think that failing to lock the file is the problem -- am I correct?

If I follow your suggestion, I might learn, eventually that there was a collision between two users, causing the file not to be updated properly. What might I learn from this -- if that's what's happening, what would I do as an alternative?

I should mention that this occurs, as expected, very infrequently -- I have a new file each month, and the first failure this month was on the 21st. In December, on the 18th. Looks like no failures in October or December.

What would your opinion be of attempting to open the file exclusively, looping until it's available?

Jim


>>Naomi --
>>
>>Both reasonable suggestions, which I will try ...
>>
>>Is what is going wrong here some failure when two people try to insert at the same time? No automatic file locking? (Just trying to understand the root cause).
>
>This is actually quite interesting (and I'm sure these are on the list of words you didn't want to hear :). Fox is supposed to all the house cleanup, flushing, buffer purity checking etc when closing the file. The only thing that I imagine could go wrong here is that the dbf header somehow isn't updated properly with the current reccount() if two users are adding their records simultaneously (well, within some minimal timeframe).
>
>I see a way to track this by writing a log of these writings into user files (just the PK and a datetime, but maybe the complete record too - up to you), and also checking to see whether the write actually took place - the recc() before and after, reopening the table to see whether the record is really there etc. All of this is just for debugging, of course.