Laserfiche WebLink
The contents of this table would be compared to the contents of the <br />accompanying ?verify? table to see if these changes are valid. Two more data <br />subset tables will be produced from this matching exercise. The subset table <br />that contains the matching records can be applied against the database. The <br />table that contains the non-matching records will be exported to an ASCII data <br />file and set aside for review by the State?s management team. <br />Subset 3-Records that fail a dependency test within the database. <br />The records in this table contain foreign key values for non-existent records in <br />other tables in the database. These records ?depend? on other tables having <br />certain records already in place, and in every case, those other records aren?t <br />in the database. <br />Example: An incoming diversion record is for a non-existing structure. To <br />ensure the integrity of the production database, a diversion record must be <br />associated with an existing structure; therefore, this record should be set aside <br />for review by the State?s management team and for checking the record <br />counts. <br />Example: An incoming station record might, in actuality, be a new station. <br />However, the record contains a value for geoloc_num that does not exist in the <br />geoloc table. Once again, the referential integrity rules of the database state <br />that a station must be associated with an existing geoloc; therefore, this record <br />should be set aside for review by the State?s management team and for <br />checking the record counts. <br />Subset 4-Change records that are not present in the ?verify? file. <br />The records in this table would be intended to change existing data in the <br />database. However, there would be no matching record present in the ?verify? <br />file to confirm this change record. <br />It is also possible that the ?verify? file could contain data items that do not <br />meet all of the necessary requirements for use in the database refresh process. <br />Any data items in question should be set aside, exported to an external ASCII <br />file, and sent to the State?s management team for review. <br />Irrigated Acreage <br />Each incoming data set may contain much more than the actual data that are to refresh the database. <br />There may be substantial historical data interwoven with the expected update year data. The primary <br />goal of this verification exercise is to end with data files that contain only data that can be applied <br />against the CRDSS database tables. <br />The incoming irrigated acreage refresh data sets (i.e., data intended for the ?polyirr_def? and/or the <br />?irrig_ts? tables) will be loaded into temporary database tables. If secondary ?verify? data sets are <br />present (applicable for State-supplied data), they will also be loaded into temporary database tables. <br />8 <br />a320/taskmems/ 2-13-01.doc 01/03/97 <br />