Ooops! I sent my original reply to myself and not sure how to delete it. )-:

Doug,

>>When you're in a transaction, VFP manages all the locks it needs on the table, so it's already locked the record for you. Any reason why you're doing the RLOCK() yourself?<<

Should optimistic row buffering be enough to prevent concurrency errors? I have several users who scan garments simultaneously and it is very possible that at any given time they would be working on the same group of items and thereby updating the same record, which contains summary counts. I am worried that if two or more users can grab the same record at the same time, since only one of them will be able to save first, someone's change could be overwritten by the other user. Depending on who gets to save his work first, the counts would come up short. I have been thinking about pessimistic buffering but I might encounter similar problem that I am already having with rlock(). I need some more guidance, please.

Thank you,
Evelyn