Tracking Updates to the DMSII Database
This chapter covers the tracking of updates to the DMSII database by the Databridge Flat File Client. The Flat File Client tracks updates to a data set (or a table mapped from a data set) by writing them to a flat file that contains some meta-data columns that identify things like the update type. This is very similar to the concept of history tables that the relational database clients support. In addition, it explains how to deal with DMSII reorganizations.
Creating the Update Flat Files
The system tracks DMSII updates by adding a record that contains the
DMSII record data to the corresponding flat file with some meta-data
columns added. Updates that involve the addition, deletion, or
modification of a record are represented by a column that specifies the
update type and the actual record data. The Flat File Client offers two
choices for this column, mainly the numeric
update_type column or the
change_code column that the DBSPAN accessory uses. See
the table in Defining a Data Source of this manual for
details on these columns.
Extracts, fixups and updates can be written to
the same set of files (one per table) or to a different set of files
(one set for extracts, one for fixups, and one for updates). The
directories where these files reside are defined by the
updates_dir parameters in the
[PCSpan] section of
the Client Configuration Files. They are described in Client Configuration Files in the Appendix of this manual. If using a single set of files, you will likely want to include the mode column in the files.
You can save updates in the Databridge Flat File Client
data files by executing the
process command each time you want to
process the updates, or you can schedule a
process command. See
Scheduling Updates in Chapter 4 of the Client Administrator's Guide for details on
Anomalies That Can Occur In Updates
When the Databridge Flat File Client updates the data files, the following anomalies can occur:
|Last quiet point (QPT) in an audit file||When processing an update transaction group since the last quiet point, DBEngine or DBEnterprise does the following when it reaches the end of the last available audit file:
|Host application rolls back changes. See Rollbacks for more information.||If a host application encounters an error condition while updating the DMSII database, it rolls back all of the changes it made. In this case, DBEngine aborts the updates when it finds the aborted transaction indication in the audit file. DBEngine handles the situation in one of two ways based on the setting of the Engine control file parameter CONVERT REVERSALS TO UPDATES:
In order to handle these situations, the Flat File Client uses temporary files to hold the updates in a transaction group. Upon getting a COMMIT from the Databridge Engine (we use this term to refer to both DBServer on the MCP and Databridge Enterprise Server), it appends the updates for all the tables that were updated to the corresponding data files. In the case of getting an ABORT from the Databridge Engine, it does not update the data files. In both cases, the temporary files are invalidated so that they get overwritten when the Client gets the next group of updates.