Parent Child Table (part1)

Before I continue on with the Parent-Child Table Data-layer Structure or Object, I want mention that I know this is a LOT of code being thrown at you. And, I suspect that a few of you are saying "Yea..Yea. I can get this done with way less code!"  You may be right, you might be able to, but please stay with me to the end. Because I have a Suprise for you. The important thing about what I am showing you, is that you understand what I am showing you. You understand how things fit together, and how it works, and why.

So, lets proceed.  The Parent Child relationship.  It is one of the most common data-layer paradigms, if not THE most common. And honestly Thes structure can be Enormous.  When you factor in fickle users playing with a large structure, and then hitting "Cancel", such that all they have changed is undone, or NOT saved, can bring fear into the mind of any developer.

Starting off we will focus in on the Child. The reason for this is that the Child Record is almost Identical to the Single Stand-Alone Table. It has ALL the same procedures; I believe the biggest difference is a single Table Field.  This Table Field being the Foreign Key to its Parent Table.  Let's look at the example table structures.

As the Parent I'll select the Galaxy Structure, and as the Child, I'll select the SolarSystem Structure. This selection makes clear sense, every Galaxy has one or Many SolarSystems.


So, our Galaxy has: 
  • ID Primary Key, 
  • Name - VarChar(100)

SolarSystqm Table has 
  • ID Primary Key
  • GalaxyID - foreignKey link back to Galaxy\ID
  • Name - VarChar(100)
  • GRow - Integer The Galaxy Row Coordinante
  • GColumn - Integer The Galaxy Column Coordinate

The only meaningful difference from our Single Stand-alone table is the GalaxID Foreign Key. I can still see the Need for all the Procedures:

  • LoadComboBoxName()
  • LoadListViewName()
  • Find()
  • FindByName()
  • Save()
  • Delete()
  • DeleteValidate()
  • Validate()

So, now we will focus in on the rather significant additions and changes needed for the Parent Structure or Object.


Comments

Post a Comment

Popular posts from this blog

How to build this without writing Code

I'm not sure if I should do this now, because I have not explained a number of additional aspects to the code, but for those of you who are interested.  The foundation of what I shown you here, IS the foundation of code my PBXClassBuilder-Standard generates for you.  And I truly mean generates  for you. You can have all this code generated for you without writing a single line of it yourself. Now PBXClassBuilder-Standard is not perfect, it is approximately 90=95% accurate. And I am constantly tweaking it edging this number ever higher. To use PBXClassBuilder-Standard, You should start with Forms already laid out and built.  Within PBXClassBuilder-Standard you use intuitive screens to define your table structure, while linking the Table Fields to their intended form Fields.  Then link the Tables together as Parent Child, and finally you simply click buttons to generate the code, Including the SQL Code to create the tables. The Whole development process, post For...
Read more

Connecting the Forms to the Data-Layer (part 9)

Here is the whole View Code Sheet Define quitfrmSolarSystem Declare SolarSystemCustom() Declare SolarSystemSetScreen() Declare SolarSystemCreate() Declare SolarSystemModify() Declare SolarSystemDelete() Declare SolarSystemSetData() Declare SolarSystemSave() Declare SolarSystemClose() Procedure SolarSystemSetScreen() Protected String$, x, y, w, h, i, ID Shared WorkSolarSystem Protected EventID, MenuID, GadgetID, WindowID, Index Shared quitfrmSolarSystem quitfrmSolarSystem = #False If Window_frmSolarSystem() SolarSystemCustom() SetActiveWindow(#Window_frmSolarSystem) ;Set Screen Data SetGadgetText(#Gadget_frmSolarSystem_txtName, WorkSolarSystem\Name) SetGadgetText(#Gadget_frmSolarSystem_txtGrow, Str(WorkSolarSystem\GRow)) SetGadgetText(#Gadget_frmSolarSystem_txtGCol, Str(WorkSolarSystem\GCol)) SetActiveGadget(#Gadget_frmSolarSystem_txtName) Repeat EventID =WaitWindowEvent() MenuID =EventMenu() GadgetID =EventG...
Read more

Connecting the Forms to the Data-Layer (part 8)

 So now we are down to just the SolarSystem Code Sheet. This is NOT a rubberstamp of the Galaxy. The MAIN reason is that the Galaxy Records are Sourced directly from the Database, As you will recall our SolarSystem is Sourced from the Galaxy Record's Solar System Collection NOT the Database. This makes for a VERY Significant difference between in the code. Our Procedure are the save ALL the Steps are the same, the differences are in the details. Starting once again at the top, we have our declares: Define quitfrmSolarSystem Declare SolarSystemCustom() Declare SolarSystemSetScreen() Declare SolarSystemCreate() Declare SolarSystemModify() Declare SolarSystemDelete() Declare SolarSystemSetData() Declare SolarSystemSave() Declare SolarSystemClose() And then, as before the SetScreen Procedure, and Control-Loop. Procedure SolarSystemSetScreen() Protected String$, x, y, w, h, i, ID Shared WorkSolarSystem Protected EventID, MenuID, GadgetID, WindowID, Index Shared quitfrm...
Read more