>It probably occurs in a normal environment, too, but less frequently. What I don't see in your code sample is how you determine and update the lookup table. Relying on the destination table only for determining a new ID fails in a number of circumstances. For example, if you use buffering, the new ID isn't visible until you issue TABLEUPDATE(). In the meantime, another instance might come up with the same value. Caches can fool VFP even more. A new record doesn't immediately become available to VFP. That is, VFP doesn't check the header or size of a table everytime you access it. Only after you added the record or when you locked the header with RLOCK(0) you can be sure that VFP sees new records.

For simplicity's sake, I left out the subroutine that grabs the next ID from the lookup table, but it is covered by an RLOCK scheme. It turns out that the TABLEUPDATE failure was simply an artifact of an upstream problem. My painfully slow debugging process via oLogger (thanks Doug!) and text files finally paid off: I had an ADDRECORD routine that was designed to use APPEND BLANK only if it couldn't grab an unused previously DELETED record. Foolish me, that method did not use any LOCKing scheme and my problem was created by the two users ending up grabbing the same deleted record and editing it separately. So when it came time to SAVE, all hell broke loose. When I cleared up that mess, the problem went away. I'm still not sure why this occured in TS sessions and not otherwise, but Neil's point about the much faster speed is probably pertinent and write caching on the server may have been implicated as well.

Thanks for your feedback, it helped focus my attention in the right direction.