With VFP 5.0, I saw the problem you described with the header lock, creating multi-user contention problems. That problem went away with 6.0, best I can tell, as you describe. Now there is this problem.

I have so far seen this problem with VFP6.0, no SP. (1 & 2 are probably the same). I haven't seen it yet with SP3, but I haven't distributed any SP3 installations yet either. I may have also seen it with VFP 5.0, but I'm not sure because at the time I didn't know what I was looking for. I did see unexplainable problems with similar symptoms but I always wrote them off to "standard" file corruption problems.

But I can tell you this: with VFP6.0, I've had three separate customers report these same symptoms, with two different applications, running on a variety of platforms (Novell, NT, different clients). I have not yet come up with a good way to reproduce the error on my own yet, since I'm not sure what conditions make it happen. Your suggestion about multi-user is a good one - that would make some sense, if the Transaction allowed the record to be written even if the header can not be updated.

If I take the data set that is bad, with tables I've never opened before, and use it on my system it does not correct itself unless I add a record OUTSIDE of a transaction. So this would definately suggest that at the very least, the Transaction mechanism itself does not check for the actual file size when it attempts to append a record, and instead writes from the calculated position of end-of-file. I can prove this by screwing up a table and writing a short little .prg to test it, which I will. If it turns out to be so I will forward it to you.

How would one report a bug to MS?

>>The reason I'm so annoyed is because I know that these types of problems have always been the bane of XBase, and I can't figure why MS decided to use what appears to be two different mechansims for update: one that fixes the problem and one that makes it worse.
>
>Your annoyance is understood, but that doesn't change the fact that this is very likely NOT VFP's fault. I don't understand why the file doesn't fix itself after the first problem, unless that same user continues to append reords without the table being closed and reopened.
>
>Is this with 6.0?
>
>Transactions do not change anything about the tableupdate process. They cause the behavior to be;
>
>1) Secure all locks that are necessary to complete the tableupdate
>2) continue until end transaction
>3) at end transaction actually do the updates.
>
>I recall that a change was made to transactions in the recent past, perhaps wht 6.0 or SP3 that stopped getting and holding the ehader lock as doing that cuase donly one user to be able to append a record at a time even though they were appending different records. If that was the cause then I would expect it to occur every time two users simultaneously append records. If that is the case then this is a bug and should be reported to MS pronto.