"I find it worthwhile to use pessimistic row buffering on the parent table and test for locks or trap "In use" errors in the error event"

How would you do this? Specifically the IN USE error?

Thanks
>Hi Nancy -----
>
>Lurkers? The UT's got no steekin lurkers :-)
>
>>With all due respect, Michelle (and to any *lurkers*), buffering and transactions are important to understand. I've been reading (and cringing) through this thread at the thought of just sticking in table buffering and tableupdates everywhere because it *seems* to do the job. The problem overcome may indeed really need a different resolution.
>
>That being said, buffering is a tough nut to crack and it's hard to get started with it. I recently gave a talk at the local FUG on an Introduction to Data Buffering and published the notes from the talk with some extra commentary here on the UT (in the Articles section, of course).
>
>If I have an application that is "Edit on Demand", I'll use optimistic row buffering for the parent record and table buffering on the child tables (although usually I use views as children but that's another topic altogether). If the application is "Edit on Request" -- meaning that there is an Edit button --- I find it worthwhile to use pessimistic row buffering on the parent table and test for locks or trap "In use" errors in the error event.
>
>Of course, you can always "always use optimistic table buffering" and control what gets saved by specifying =TABLEUPDATE(0,.F.) which only commits the current row and GETNEXTMODIFIED() to navigate. It's not efficient but it can be done with little or no concern.
>
>Oh, and I agree with your reference to Jim Booth's book....it is, indeed, a great reference.