>>So far I have been creating one BIZ object for one table. But I am wondering if there is a better design for cases of parent/child tables and ancillary tables. For example, P.O. Header table and P.O. Item table. One approach I am considering is to instantiate P.O. items BIZ object in the INIT of the P.O. Header BIZ object. And then "deal" with any updates for P.O. Items within P.O. Header BiZ object. How do you design your BIZ objects for the cases of parent/child tables?
>>
>>Right now, I am tinkering with the DataEnvironment (DE) as my BIZ Object, then use CursorAdapters (CA) as 'representations' of each table. Since the DE is a container, it would be easy to handle its CA members.
>>
>>Just my two cents. =)
>>
>Very interesting approach. I will think about it. Thank you.

The problem with that approach is that ONLY the DE can have child objects. Similar to your approach I have child objects where necessary, but not all children are data children - sometimes they are added to provide biz functionality. Data children have a CA associated in a property, as custom cannot addobject them. But this way modelling becomes easier for my way of thinking

regards

thomas.