Hi Ray,

>I still don't understand, however, why this would occur in a TS session but not in a traditional client/server environment????

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.