>>The help file doesn't directly state, but implies that Tableupdate() will >>generate an error if nRows is set to 1 and table buffering is enabled. I have >>actually seen it set off my error handler before, so I know that it works.

Go back and re-read the help file. It states tableupdate() will return .T. or .F. indicating success or failure. This does not mean it will raise an exception! It also says, like I said too, to test result with AERROR().

>>Also, pessimistic buffering is only set on one table
Forget about pessimitic buffering, its not good practice. See the previous thread for an explanation.

>>would you know of any resources (samples, tutorials, real world situations, >>etc) that would help aid my understanding of locking/buffering/transactions >>etc.? I am **so** close to making this thing work but have run into some real >>stumbling blocks at the end.

Locking and buffering is taken care of for you automatically if you have it turned on. Transactions are only usefull for all or nothing updating. Don't make it any harder than it has to be.

Once you get the hang of working in a multi-user environment, start thinking how you can encapsulate your data handling behavoir into generic business objects. I never write any data handling code anymore, instead my custom business objects use subclasses of the base cursor and dataenvirnoment classes. The only thing I have to add is the validation code which always unique to each cursor.

Charlie