Clinic A and Clinic B periodically send data files to an agency called Central, where they are merged into the Central database. The process would be similar for a regional, national, or corporate database, or the collection point for a multicenter study.
In contrast to the MERGE UPDATE used to insert new lab data into the clinic records, we will now be using MERGE UPDATE APPEND. Records not already present at the Central database will be APPENDed to it. Data in existing records that may have changed since the last MERGE will be UPDATEd by values in incoming Records from the Clinics.
Merging a single table such as CLIENT from one of the clinics is a fairly simple operation. You READ the CLIENT table in CENTRAL.MDB and then use MERGE with UPDATE and APPEND to bring in the data from the CLIENT table in a clinic. What keys should you use for the match? In this case the CLIENT ID and the CLINIC identifier (A or B) will uniquely identify each record.
Our demo database scheme, however, is more complicated than a single-level table. Each CLIENT has 0 or more VISIT records, and these also are to be merged to Central. At first we treat theCLIENT and VISIT Views as separate databases—READ the Central CLIENT View and MERGE the Clinic CLIENT View with it. Then we do the same for VISIT Views, READing the VISIT View for Central and MERGING first one Clinic VISIT View and then the other. To do this, we need an extra key, the DATEOFVISIT, since Client ID and CLINIC are not enough to uniquely identify a VISIT.
Exit from the browser (X in the upper right corner) to see Central database before and after MERGING data from Clinics A and B.