>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
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only