Some great suggestions!

To summarize (as best as I can):
1) open the child table in the form init() if necessary
PROS: very simple if your child form consists of a single table
need only a single form for both cases
CONS: no visual representation of child data environment (no big deal if it is simple)
need to make sure alias for table opened in child matches parent

2) create a base edit form, then subclass 1 w/priv datasession and 1 w/dflt ds
PROS: classes really model reality
no extra code in the class to deal with changing datasessions
CONS: have to design form in form designer and paste into class or else you cannot bind controls (since there is no DE in classes)
have 2 different forms and need to launch different form

I came up with one other suggestion (comments/criticism appreciated):
3) create a private datasession for the child, that contains the tables needed when launched w/out the parent
pass the DataSessionID from the parent to the child
in the child init(), change the DataSessionID if a new one is passed in
PROS: a single form, both datasessions are visual, no code
CONS: the docs says changing IDs should only be used for debugging (ouch!)

Bob