>I would not agree here. If some tables, even unbuffered, must be changed safely i.e. either all or nothing, then transaction looks very appropriate. I mean that we have some 'buffer', e.g. cursor(s) on local workstation that hold changes for these tables and we want to move these changes to real data (file-server).

Ed,

Not in a multiuser environment they don't make sense. Not ever. The transaction takes locks on the unbuffered table adn doesn;t release them until the entire transaction is completed or rooled back. Menawhile, if a new record was added, no other station can add a record to that table (the header is locked). I can see it now, "Gee, I'm sorry that you 15 telephone operators can't enter a new order at the same time, but that is how transactions work." I can't imagine the client who would accept that answer.

So, if one is not using buffering they are best advised to avoid transactions and deal with the problems of partially completed updates. Of course they could simply click a property in the property sheet to turn on buffering and not have the problem. Transactions work fine with buffered tables.