>The reason for that might lie trying to conserve COMMIT/ROLLBACK-
>type of actions while a record is edited, especially if changing one
>value causes changes in more than one table, or even more - in more
>than one database.
>...But then again, - I think we're talking here about approximately
>the same approach with very little deviation :)

the devil is in the details, u know :)
one last q. to clarify things, when u create an object for a table
does it take care of all the interaction with the table e.g SQL for that table etc.?
if u answer is no, then I guess we do talk the same approach more or less

if u answered yes is this what u do :?
IMHO if I want to create (e.g.) a proper OO customer object it has to contain both all the GUI components related to this table and methods
for accessing the different record.(to comply with encapsulation)
a specific customer object will of course be inherited from a general tabele object of the same sort
this is not impossible to write (a lot of work, as u have to implemet methods for things like views, seek,selects etc.)
but I think this adds a lot of overhead


Arnon