Entering Data in Tables in a Supertype/Subtype Relationship* Super-SubForm 4/14/2017 Entering Data in Tables in a Supertype/Subtype Relationship* If you came to this presentation via a web browser, right-click and choose “Full Screen” before proceeding. Click mouse or press space bar to continue. This presentation was prepared by Professor Steve Ross, with the advice of other MIS Faculty, for use in MIS Classes at Western Washington University. Please contact Dr. Ross for permission to use in other settings..

The Challenge Create a form for the entry of building data in the supertype and subtype tables Most database programs implement a supertype/subtype structure as a series of 1:1 relationships

Step 1 – Source Data To enter data into tables that are in a supertype/ subtype relationship, we must create a form for the “supertype” table and subforms for the “subtype” tables Create a view for each table the form affects vueFrmBuilding, vueSfrManuBuilding, and vueSfrRetailBuilding contain all fields of their respective tables

Step 1a – Source Data Determine field and control characteristics for vueFrmBuilding – the “supertype” view Field Editable Control format Constraints BuildingID No Read only text Address Yes Text box City State Zip Description Status ManagerID Combo box FK to tblWorker BuildingType values “Manufacturing” and “Retail”

Step 1b – Source Data Determine field and control characteristics for vueSfrManuBuilding – a “subtype” view * In Microsoft Access, when a record is added in the subform, the value of the parent form linking field (vueFrmBuilding.BuildingID) is automatically entered into the child form linking field (vueSfrManuBuilding.BuildingID); therefore an editable or visible control is not needed Field Editable Control format Constraints BuildingID No Not visible* FK to tblBuilding OfficeArea Yes Text box ManuArea StorageArea RailDock Check box Boolean field TruckDock

Step 1c – Source Data Determine field and control characteristics for vueSfrRetailBuilding – a “subtype” view * In Microsoft Access, when a record is added in the subform, the value of the parent form linking field (vueFrmBuilding.BuildingID) is automatically entered into the child form linking field (vueSfrRetailBuilding.BuildingID); therefore an editable or visible control is not needed Field Editable Control format Constraints BuildingID No Not visible* FK to tblBuilding TotalArea Yes Text box RetailArea CommonArea FoodCourt Check box Boolean field ParkingArea

Designing for Usability: Subtypes in Subforms The primary key of the supertype table is both a primary key and foreign key in the subtype table A foreign key that relates the subform table to the parent form table is entered automatically by Access when data are entered in the subform If there is a possibility that users will not enter data in the subform, then steps must be taken to ensure a record is created – see Step 6

Designing for Usability: Subtypes in Subforms (cont’d) The subtype discriminator (either a single field or set of Boolean attributes) can be used to control which subform(s) are visible or enabled. If disjoint, then only the relevant subform should be visible If overlapping, then all relevant subforms might be visible, depending on the values of the Boolean fields The remainder of this example illustrates the technique for a “disjoint” situation

Step 2 – Layout Create a draft view of the form – in this case I chose to modify an existing form This will be a combo box, bound to the BuildingType field, that allows the user to choose one type This area contains data entry controls for the selected subtype entity; visible only when the matching subtype is chosen Subtype table field Subtype table field Subtype table field Subtype table field Subtype table field

Step 3a – Create Version 1 of the Main Form Use the “supertype” view created in Step 1 (vueFrmBuilding) as the record source

Step 3b – Add First Subform Use a “subtype” view as the record source

Step 3c – Add Other Subforms Add subforms for the other views. At this point, I usually stagger their positions for ease of editing.

Step 4a – Fine Tuning, Main Form Convert the “subtype discriminator” controls to combo boxes or check boxes as appropriate In this example, a combo box is required Control name changed on “Other” tab The Row Source property contains the allowable values An alternative would be to link to a table or view of building types Important settings

Step 4b – Fine Tuning, Subforms Open subform in design view Convert any “foreign key” controls to combo boxes Change the default view to Single Form Disable settings that pertain to multiple records (because there’s only one instance of a subtype related to an instance of the supertype) Important settings

Step 5 – Subform Visibility Control Use VBA Code and the value of the subtype discriminator combo box to control the visibility of the subforms [code samples on following slide] Subroutine that sets visible property to True or False based on value of combo box – called by the following For the parent form, an On Current event that will execute the subroutine each time a new record is displayed For the combo box, an After Update event that will execute the subroutine each time the value of the combo box changes

Step 5 (cont’d) Executes with each new record, including the first Private Sub Form_Current() 'make all subforms invisible at first sfrManuBuilding.Visible = False sfrRetailBuilding.Visible = False 'turn on a subform if building type is known subShowSubform End Sub Private Sub cboBuildingType_AfterUpdate() 'Subroutine displays subform based on value of combo box Private Sub subShowSubform() Select Case cboBuildingType Case "Manufacturing" sfrManuBuilding.Visible = True Case "Retail" sfrRetailBuilding.Visible = True End Select Executes with each new record, including the first Executes after the value of the combo box is changed Subroutine called by the two event handlers

Step 6 – Subtype Record Creation Making the subform visible does not create a record in the subtype table. Only when data are entered into one of the subtype table fields is a record created. In some circumstances, you must ensure that a record is created in the subtype table e.g., when the table is part of another relationship VBA Code can be used to Determine whether a record already exists If not, create one

Step 6 (cont’d) Before you enter code ... Check the table structure of the subtype tables Access often sets the default value of numeric fields to 0 (zero) The primary/foreign key field should not have a default value ... if a default value is present, erase it Each form for the subtype tables should have a control for the primary/foreign key field I usually set visibility to “No” because it duplicates information on the main form … If you leave it visible, ensure that it cannot be edited by the user Recommended name: txtSubBuildingID Recommendation: name the PK control on the main form: txtSubBuildingID

Step 6 (cont’d) NOTE: This Slide applies to Access 2010 and later Previously-existing subroutine has been edited to add new logic Private Sub cboBuildingType_AfterUpdate() subShowSubform 'save the record to ensure the identity field is populated DoCmd.RunCommand (acCmdSaveRecord) 'force the subform to create a new record if none exists Dim SuperBuildingID As Integer 'create and populate a variable SuperBuildingID = txtSuperBuildingID 'containing the supertype table PK value Select Case cboBuildingType Case "Manufacturing" sfrManuBuilding.SetFocus If ([Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value) = "" Then [Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value = SuperBuildingID End If Case "Retail" sfrRetailBuilding.SetFocus If ([Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value) = "" Then [Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value = SuperBuildingID End Select End Sub Executes once the subform is visible

Step 6 (cont’d) NOTE: This Slide applies to Access 2007 and earlier Previously-existing subroutine has been edited to add new logic Private Sub cboBuildingType_AfterUpdate() subShowSubform 'save the record to ensure the identity field is populated DoCmd.RunCommand (acCmdSaveRecord) 'force the subform to create a new record if none exists Dim SuperBuildingID As Integer 'create and populate a variable SuperBuildingID = txtSuperBuildingID 'containing the supertype table PK value Select Case cboBuildingType Case "Manufacturing" sfrManuBuilding.SetFocus If IsNull([Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value) Then [Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value = SuperBuildingID End If Case "Retail" sfrRetailBuilding.SetFocus If IsNull([Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value) Then [Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value = SuperBuildingID End Select End Sub Executes once the subform is visible

Step 7 – Finish the Forms Apply check constraints and other properties to controls. Once controls are set, apply other design standards.* * The form illustrated here met all MIS 421 design standards when it was created. Subsequent changes to the standards may have occurred.

Step 8 – Quality Assurance Can the user change data in an existing record in the “supertype” view? in the “subtype” views? Can the user enter new records Does switching from one subtype to another cause the appropriate subform to be visible? Is a record created in the subtype table when that type is chosen on the main form? Are all constraints working properly? (Test the limits.) Have all Design Standards been met?

Points to Ponder The form created in this example Partial, not full specialization Disjoint, not overlap Allows the subtype to change Retains old subtype data after change What changes would be required if … Full specialization were to be enforced? Overlap were permissible? The subtype was fixed, not changeable? Prior subtype data were to be deleted on change?