>>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....