Hi Roy,

<snip>

>- if I'm updating multiple tables in this screen then have a business layer object for each table that I'm updating?

My framework is a 4-tier system that separates table access from validation-type stuff and keeps the UI just about completely uncoupled from the data. But my suite of data objects does the same kind of data I/O stuff that your business object will do, and it provides navigation and update conflict handling as well. My system works with parent-child recordsets. The data manager class can handle one parent record and, optionally, any number of child records in any number of tables. I therefore have one data object subclass for each such combined parent-child set. All I have to do to subclass it for a lone parent table is provide the name of that table in a class property. If I want to use child data with the parent record, I just put the list of child tables, with some structural information, in an array in one hook method of the subclass. If I wanted to take the route of creating a fairly complex data dictionary, it wouldn't be too much of a step to have that hook method just read the child table information out of the data dictionary.

So far I haven't had a need to invoke private datasessions, so I've avoided having to wrap my brain around that issue up to now. So these classes are based on the Custom baseclass, but it would only take changing one line of code to change them to Session-based, because they're all .prg classes.

It did take quite a while to create these classes, but they are very easy to use and pretty bulletproof. They are also idiosyncratic to my own, shall we say, peculiar strengths and weaknesses as a developer. But I thought you might find this interesting as a response to your question about subclassing business objects.