Ravi,

>>I'm curious to know...were you doing a tableupdate() after your UPDATE and INSERT statements? I would think so, or else those wouldn't work either.
>>
>Nope. I am not doing a tableupdate() after the Insert. Just tested it. However, the Update does not work now. Do I have to add the tableupdate() code after the Update statement?
>

Yes, you need tableupdate() there, too...

>>In order to delete a record, it is not required that you have the table buffered. But SINCE you were buffering the table (with a mode of 5), you had to do a tableupdate() to write the change (a delete, in this case) to disk.
>
>Is any other way of bufferring preferred?
>

I don't suppose I'm qualified to say what is generally preferred. You have to decide if your system needs be optimistic, or pessimistic. Optimistic buffering won't lock a record until the tableupdate() occurs. If someone else has made changes to the same record, you have to deal with it then. Pessimistic buffering locks the record as soon as a change is made to the buffered record (before the tableupdate()).

Of the buffering modes, 4 and 5 (table-level) provide you with the most control. With modes 2 & 3, tableupdate() occurs when the record pointer moves, whether you are ready or not.

I think some people still use a non-buffered, pessimistic approach...manually issuing RLOCK() when a user wants to edit a record.

Conclusion: I think mode 5 & 4 might be the preferred choices.

>>Another option is to use an updateable view, and an updateable view is buffered. You can then bind the view's fields to the controls on your form. When using views, tableupdate() is used to send the changes back to the table.
>
>I always thought of the cursor as a view - so much for my VFP knowledge!
>

They are similar...differences are covered in 1000 Things book.

>>
>>Do you have either 1000 Things or Effective Techniques from Hentzenwerke? Both books have discussions on buffering and on views that you should find very informative.
>
>I will get them.

HTH,