>Edward-
>
>>Do you mean 'unavailable' in as sense that multiple locks will interrupt other users working with data? I do not think that's critical, because transaction is dynamical, i.e. locks will be applied for short period of time and SET REPROCESS will take care of this. Anyway, locks will be applied to real tables, not to buffers.
>
>I mean that using transactions on buffered tables is only useful if you do all your processing within the transaction (add, delete, edit records). Since that's the case (as I understand transactions), the tables are indeed unavailable to others.
>
>For example, open two VFP sessions. Use a table in one, begin a transaction, and then append blank in a table. Switch to the 2nd session and use that table (notice you don't see the same record count), and append blank or delete. You'll get the message that the record is not available.
>
>Now, consider that the person adding an invoice (for example) for a customer. They add the record and find some problem...like their coffee cup is empty...they go off to find an answer..or get more coffee :)... Meanwhile the other poor sap is stuck.
>
>Do you see what I mean? It's dangerous, IMO, especially since implementing buffering is so painless.

Now I see what you mean. I have never used transactions this way. IMO, transaction is suited for applying changes to multiple tables at the same time and dynamically. Let say, we have cmdSave.click code that writes changes to three tables (one parent and two childs) and it's required to provide that changes will be really written to all tables, even if something will happen dow the road (e.g you wrote changes to the first child and then found parent record locked). In case you described (static), it's not job for transaction, it's really buffering (standard or simulated) task.