a) TbLevelOne
 b) TbLevelTwo with TbLevelOne
 c) TbLevelThree with TbLevelTwo

It considers three edition forms now:

 a) FormTbLevelOne with:
  . tbLevelOneBO1
  . tbLevelTwoBO1
  . childFormDialog1 (FormTbLevelOne.tbLevelTwoBO1 <-> FormTbLevelTwoEditor.tbLevelTwoBO1)

 b) FormTbLevelTwoEditor
  . tbLevelTwoBO1
  . tbLevelThreeBO1
  . childFormDialog1 (FormTbLevelTwo.tbLevelThreeBO1 <-> FormTbLevelTheeEditor.tbLevelThreeBO1)

 c) FormTbLevelThreeEditor
  . tbLevelThreeBO1

It also considers that the relationships between the levels had been filled correctly.

 a) TbLevelTwo.ParentRelationship: TbLevelOneBO, (IdLevelOne) <--> (IdLevelOne)
 b) TbLevelThree.ParentRelationship: TbLevelTwoBO, (IdLevelTwo) <--> (IdLevelTwo)

The result was (Primary key/foreign key synchronization):
 
 a) FormTbLevelTwoEditor:  OK
 b) FormTbLevelThreeEditor:  Not OK (Primary key of the TbLevelTwo automatically is not created in the TbLevelThree.)

I am annexing a project example, with the database.

OK...the problem that you ran into is a BO translation issue that I found the other day myself when you nest too deep.  This will be fixed, but you can get around this extremely easily.  The problem that you had was when you were in level 2 adding a record for level 3.  If you override the OnLoad method and after the base class is called, manually set the ParentBusinessObject properties, everything will work.  In your example, I just added this code above the tbLevelThreeBO1.Add() call to resolve the problem, but you don't really need to do this everytime and can get around the problem by placing this same code in the OnLoad after the base class is called: