>Hi,
>
>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?

I usually treat child tables as belonging to parent table BO, therefore no separate object for them, unless they have use independently from parent table. In other words all handling is done within parent BO. All my BOs are based on session object (parent class) and done inside PRG. Here is one over simpliified mockup example ;

local oBO
oBO=createobject('MyOrders')

oBO.ShowList()

oBO.EditOrder(993344)
oBO.DeleteOrder(993344)

oBO.PrintOrderList()
*etc


define class MyOrders as myBO &&parent class based on session object


  procedure OpenTables
    **open tables directly or fetch data from backend
     use Clients in 0 shared &&order ...
     use Orders in 0 shared
     use OrderItems in 0 shared

  procedure ShowList
  **show some form so user view / select from list of orders


   procedure EditOrder
   lparameters nOrderId
     *show order form
     local ok_pressed
     do form (cOrderScx) with this to ok_pressed
        if ok_pressed
         this.SaveAll()   &&parent class generic method or subclass specific 
          else
        this.RevertAll() &&parent class generic method
       endif


    procedure DeleteOrder
    lparameters nOrderId
    **Show dialog
    **delete  child records
    **delete parent record
    this.SaveAll()

    procedure AddOrder
      *add new record 
      *show edit form 
     local ok_pressed
      do form (cOrderScx) with this to ok_pressed
      if ok_pressed
        this.SaveAll()   &&parent class generic method or subclass specific 
      else
       this.RevertAll() &&parent class generic method
     endif


    procedure ValidateOrder
         *validate record 

    procedure ShowLookup
       lparameters nCustId
      *show lookup form
     do form (cOrderLookupScx) with this to nSomeRecordId
     return nSomeRecordId

    procedure PrintOrderList 
       *extract / preprocess data
       report form (cOrderFRX) to printer preview

    procedure CalculateOrder
    **calculations



     *etc


enddefine


define class myBO as session  &&parent class for all BOs

   procedure init
      this.OpenTables()


   procedure SaveAll
      *depend on architecture, saving buffered data or sending updates to backend

   procedure RevertAll
      *depend on architecture

   procedure DeleteCascade

*etc


enddefine

You might frawn at use of prg, but flexibility you get this way is just simply amazing.
You can call these objects literally from anywhere (can be even exposed as COM object), related BOs can call each other
very easy, you avoid Form.DE problems, get much better (fully controllable) *formset* (set of connected forms) and many other things. You pass entire object to all forms that are called, store object reference in some property and then all UI forms can call their undelying BO methods very easy.

**form init method
lParameters oBO
this.oBO=oBO   &&store BO object ref to form property 

**Then anywhere in the form code (Some button click method, textbox validation etc) 
*some form method
.
if  thisform.oBO.ValidateOrder() 

  **action  when valid
  else
  **action when invalid

endif

Forms should contain as little of code as possible themselves. Just some controls handling if necessary and calling
BO methods.

Worked very good for me for past 10 years or so :)


HTH
Sergio