PAHLabs

 Welcome back! Continuing on with the Save Procedure.  In order for the children to be linked to their Parent, the Parent MUST be saved prior to the children.  So, lets focus in on the bottom end of the SQL INSERT: PassFail = DB::Update(DBID, Sql$) If PassFail *Class\State = DB::#Clean *Class\ID = DB::getLastID(DBID, "Galaxy") EndIf DB::Close(DBID) ;----------------------------------------------- SaveSolarSystemCollection(*Class) ;----------------------------------------------- As you can see once we close the database and retrieve the Parent's ID from the database, we then call the Save Children Procedure.  On the SQL UPDATE, we are free to call the Child Save Procedure immediately after the Close Procedure. PassFail = DB::Update(DBID, Sql$) If PassFail *Class\State = DB::#Clean EndIf DB::Close(DBID) ;--------------------...

 Moving on to the Find Methods.  Here again we have some changes. After we load up our Parent Record, we then need to load up its children.  I'll focus in on the in the code segment below: PassFail = DB::Query(DBID, Sql$) If PassFail While NextDatabaseRow(DBID) With *Class \ID = GetDatabaseLong(DBID, DatabaseColumnIndex(DBID,"ID")) \Name = GetDatabaseString(DBID, DatabaseColumnIndex(DBID,"Name")) \State = DB::#Clean EndWith Wend EndIf DB::Close(DBID) ClearList(*Class\SolarSystemCollection.SOLARSYSTEM::SolarSystem()) ;----------------------------------------------- LoadSolarSystemCollection(*Class) ;----------------------------------------------- ProcedureReturn PassFail Here you can see After the Parent Record is loaded, and the database Closed, we then Clear the List in preparation for loading it, then we call a new Procedure to Load the Child Collection. ...

Our First difference will be in the Structure definition. Structure Galaxy ID.i ; Table Primary Key Name.s ; Name of Galaxy List SolarSystemCollection.SOLARSYSTEM::SolarSystem() List DeleteSolarSystemCollection.SOLARSYSTEM::SolarSystem() State.i EndStructure As you can see, I've added in two Lists. The first: SolarSystemCollection which is a List of our Child Collection Records. And the second is called DeleteSolarSystemCollection which also is a List of our Child Collection Records. Now EACH of our Parent Records can contain the Children linked to it.  Now let us go through the Procedures and make the necessary changes to accommodate these Child Lists. The First Change we'll have will be to the Init and Dispose Methods. Procedure Dispose(*Class.Galaxy) ;Dispose all Child Collections ForEach SolarSystemCollection() SOLARSYSTEM::Dispose(@SolarSystemCollection()) Next FreeList(SolarSystem...

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 a...

 The Final post in this series on the Stand-alone table Module is the Validate Procedure. As with the DeleteValidate Procedure this procedure has two functions, first validating the Structure of Object, but it also has the job to report All issues it found back to the user. The following list of validations should be performed for the FighterSize Table. All String Field Lengths to ensure they are within the size limits defined in our database. Not Null, for every field defined as not null we should perform a not null validation. Unique Test. All fields which need to be Unique are, in fact Unique. In addition to these any other req2uirements you need should be tested here. The following is the Validation Procedure of my FighterSize Table Procedure.i Validate(*Class.FighterSize) Protected DBID, Sql$, PassFail.i = #True Protected ErrMsg.s = "" If Len(*Class\Name) < 1 PassFail = #False ErrMsg = ErrMsg + "Name cannot be less than 1 characters ...

  The following is our completed Module: XIncludeFile "../Utils/ThemedMessage.pbi" XIncludeFile "DB.pbi" DeclareModule FIGHTERSIZE Structure FighterSize ID.i ; Table Primary Key Name.s ; FighterSize Name UnitDescription.s ; Short description UnitTypeID.i ; Foreign Key to Type UnitType VisibleWithTechnologyLevelID.i ; Foreign Key to Table TechnologyLevel IsHidden.i ; Boolean field GameImageID.i ; Foreign Key to Table GameImage Space.i ; the volume of space inside the ship ProdCost.i ; Cost to Produce ProdTime.i ; Time it takes to produce in Game turns Attack.i ; Fighter's attack Value Defense.i ; Fighter's Definse Value State.i EndStructure Declare LoadComboName(c...

 This brings up to the Delete Procedure, and the DeleteValidate Procedure. These we will explain in this post. Just as the Save Procedure call a Validate Procedure, so the Delete Procedure call a DeleteValidate Procedure.   In this manner you can easily insert code to ensure the record being deleted is not being "used" or referenced elsewhere in your application. The Delete itself is very straight forward. Procedure.i Delete(*Class.FighterSize) Protected Result, DBID Protected Sql$ If DeleteValidate(*Class) = #False ProcedureReturn #False Else DBID = DB::Open(DBTYPE::#Sqlite) SetDatabaseLong(DBID, 0, *Class\ID) Sql$ = " DELETE " Sql$ = Sql$ + "FROM " Sql$ = Sql$ + "FighterSize " Sql$ = Sql$ + "WHERE " Sql$ = Sql$ + "ID = ? " Result = DB::Update(DBID, Sql$) DB::Close(DBID) ProcedureReturn Result EndIf If the Record is approved for del...