Posts

Showing posts with the label data-layer

Parent Child Table (part 4)

 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) ;--------------------...

Single or stand-alone table (part 6)

  Now we are getting to the true meat of the Module! Though SQL separates the Insertion from the Update, I feel it is NOT the Form code's responsibility to make this decision. The Goal is to remove this from the Form and put this decision into the Data Layer. Therefore, these two are combined into a single and simple Save Method. The steps necessary to Insert and Update are the same, combining the is the only way to not have redundant code. in pseudo code the steps are pretty straight forward: If Validate Data = TRUE     IF New, then Insert         Update Data ID, set to Clean     ELSE Update         Set to Clean ELSE Sent Error Message(s) Let's take a Look at the Save Method, and then I'll walk you through it. Procedure.i Save(*Class.FighterSize) Protected Sql$, Result, DBID, Length, *MemoryGraphicID Protected PassFail = #False If Validate(*Class) = #False ProcedureReturn #False Else ...

Single or stand-alone table (part 5)

 Now we are getting to the true meat of the Module! This begins with the Find procedure.  This Procedure retrieves a specific record from the database.  All Table Modules should have a default Find using the table's primary key to retrieve data. Other finds may be necessary, but they will all look the same only the passed in data and SQL Where clause need to be modified to accommodate the unique value being searched for.  All Finds should retrieve only 0 or 1 Record, never multiple. When Creating Find methods you should Always Unique Fields, as ensured through the Validation Procedure. Let's take a Look at the Find Method, and then I'll walk you through it. Procedure.i Find(FighterSizeID.i, *Class.FighterSize) Protected Sql$, DBID, Result, PictureSize, *picture, BLOBSize Protected PassFail = #False Init(*Class) DBID = DB::Open(DBTYPE::#Sqlite) SetDatabaseLong(DBID, 0, FighterSizeID) Sql$ = "SELECT " Sql$ = Sql$ + "ID, " ...

The Single or stand-alone table (part 3)

Welcome Back! In my previous entry we defined the needed Procedures in a Stand-Alone table data layer Module.  In this blog entry we will begin to build out these Procedures. The first step in building the FighterSize Module is to create our public interface, or Public Declares. Declare LoadComboName(cbData.i) Declare LoadListViewName(lvData.i) Declare LoadListIcon(liData.i) Declare.i Init(*Class.FighterSize) Declare.i Find(FighterSizeID.i, *Class.FighterSize) Declare.i FindByName(FighterName.s, *Class.FighterSize) Declare.i Save(*Class.FighterSize) Declare.i Delete(*Class.FighterSize) Declare.i Validate(*Class.FighterSize) Declare.i DeleteValidate(*Class.FighterSize) Before we dive into creating our public procedures there are a couple of housekeeping things we need to address first. Our first Procedures to create will be Private Procedures.  We are going to build an Initialize and a Dispose Procedure. These will be called by our Public Procedures to ...