In order to store a crash record and three vehicles, there need to be four "Update locations". Each field must be assigned to an update location. An update location specifies a connection to a database, a table within that database to update, and a "do write" expression. The do write expression is used to specify whether a particular row should be written. It is frequently used to prevent writing vehicles 2 or 3, or other rows for data that wasn't entered.
For our example, we will create the following update locations:
•Main
This "Main" update location indicates that it will connect with using the "DataEntry" connection. This, or the "Writer" connection typically provide read/write access the database. This update location writes to the "Collisions" table. Since the Do write expression is "true", saving a record will always result in any fields associated with the "Main" update location being written to the database.
Each update location also has one or more "Unique fields" associated with it. These fields are used to load the record, and must identify it uniquely across all the data in the table that it writes to. Typically, the "main" or "environment" record type will have a single CaseId field for it's unique field. Since the unique fields for the main record are used as prompts when creating or loading a new crash record, you will note that CaseId is marked as visible. It's control type is set to string, common for case id's. The other important values here are the data settings where "Main" is specified as the update location; the Field name is "CaseId".
•Veh1
The update location for "Veh1" is much more interesting. As with the "Main" update location, it uses the DataEntry connection. Since it writes to the vehicles table, its table name is "Vehicles". But notice that the Do write expression contains quite a bit of text. This expression is testing to see if any of the fields related to Veh1 have values in them. If any single one of them has a value, (is not null) then the Veh1 record will be written to the database.
The Veh1 record also needs to know which fields make it unique in the its (Vehicles) table. In this case, a field called CaseIdVeh1 holds the CaseId field for the Veh1 record. Note that the CaseIdVeh1 field is not visible. Also, the expression is "CaseID.value". This means that when this record is written to the database, the CaseId field will contain the value from the main record's CaseId.. In addition, there is a field called VehNum1 that holds the vehicle number. Similar to the CaseIdVeh1 entry field, this one also has an expression. However in this case, that expression is simply "1". Whenever a Veh1 record is written, it will have a CaseId that matches the Main record, and a VehNum that is 1.
•Vehicle2
The Veh2 update location is very much like Veh1, but it checks for the fields that indicate properties of vehicle 2 instead of vehicle 1.
The unique fields for Veh2 are exactly the same as for Veh1, but the expression for the VehNum is a literal "2". Also note that since all entry fields in a data entry definition must have unique names, the names for these unique fields have been created using the field name and the update location name.
•Veh3
Veh3 is a bit different in this example, because in this configuration, there are only two fields that relate to vehicle 3. We are only storing the direction and the movement of a third vehicle. Even though only these two fields need to be checked for Do write, Veh3 still has the same two unique fields, similar to Veh1 and Veh2. Again, the only difference is that VehNum is hard-coded to a "3".