>>>Please clarify. A class will not aid in transactions. MaxFrame had classes and everything was done on a shared global connection. It was handled by classes. Is that what you mean?
>
>No I mean all saves/commits handled by a class that encapsulates transaction handling, error trapping etc. So rather than tableupdate() you call a method.
>
>The class could have start/end transaction functions that automatically roll back records after the first tableupdate() fails, or even something like myDB.save("Myview1,myview2,myview3") and because there's multiple views, it splits the parameter apart using alines, wraps a transaction and saves in specified sequence, rolling back if there's a fail. Something like that. If used, it could make adding stuff like transactions more seamless.
>
>>>This code is not modular enough - it's mudular. So I have to inject this approach on a case by case basis.
>
>Gotcha.
>
>Re your client: I can't see the system, but sometimes you want a master record saved even if the subrecord errors, especially if it avoids repeating bucketloads of work. That's a valid reason for sequenced saves without transactions in some situations, even if not yours....

There is no benefit to including the header record in a transaction in that case. Although you can still use a transaction to save even that record. I use transactions wrapped around everything. I see the usage of it like having face plates covering electrical outlets. They is great harm from the lack of them, versus no harm from using them and as you said, having classes makes single or multi-table commits easy. The thing is, there are so many examples where the invoice header and the line items and the inventory have to be depleted all at the same time, and when it doesn't work right, someone has to go digging. This is far from the exception.