Kernel Toolkit APIs: EN^XDRMERG

EN^XDRMERG(): Merge File Entries

Reference Type: Supported, Category: Toolkit—Duplicate Record Merge, ICR#: 2365

Description

The EN^XDRMERG API provides for merging of one or more pairs of records in a specified file. This API takes two (2) arguments:

File number (a numeric value).
Closed reference to the location where the program finds an array with subscripts indicating the record pairs to be merged (a text value).

Format

  EN^XDRMERG(file,arraynam)

Input Parameters

file:

(required) Specifies the file number of the file in which the indicated entries are to be merged.

Input / Output Parameters

arraynam:

(required) This parameter contains the name of the array as a closed root under which the subscripts indicating the FROM and TO entries are found. The data can have either two or four subscripts descendent from the array, which is passed.

REF: For examples of its usage, see the “Overview” section in the "Toolkit—Duplicate Record Merge" section in the Kernel 8.0 & Kernel Toolkit 7.3 Developer's Guide.

Examples

The following command would result in record pairs specified as subscripts in the array MYLOC to be merged in a hypothetical File #999000014:

     D EN^XDRMERG(999000014,”MYLOC”)

The array MYLOC might have been set up prior to this call in the following manner (or any equivalent way) where the subscripts represent the internal entry numbers of the FROM and TO records, respectively.

     S MYLOC(147,286)=“”,MYLOC(182,347)=“”,MYLOC(2047,192)=“”
    S MYLOC(837,492)=“”,MYLOC(298,299)=“”

This would result in five record pairs being merged with record 147 (the FROM record) being merged into record 286 (the TO record), record 182 being merged into record 347, etc., to record 298 being merged into 299. Merges using the two subscript format occurs without a specific record of the entries prior to the merge (The internal entry numbers merged would be recorded under the file number in XDR REPOINTED ENTRY [#15.3] file) An alternative is a four subscript format for the data array that uses variable pointer formats for the FROM and TO records as the third and fourth subscripts. If the merge is performed with this four subscript array, then a pre-merge image of the data of both the FROM and TO records in the primary file and all other merged files (those related by DINUM) and information on all single value pointer values modified is stored in the MERGE IMAGE (#15.4) file.

For the sample data above [assuming that the global root for the hypothetical file #999000014 is ^DIZ(999000014,] the four subscript array might be generated using the following code:

     S MYROOT=“;DIZ(99900014,”  <--- note the leading ^ is omitted
     S MYLOC(147,286,147_MYROOT,286_MYROOT)=“”
     S MYLOC(182,347,182_MYROOT,347_MYROOT)=“”
     S MYLOC(2047,192,2047_MYROOT,192_MYROOT)=“”
     S MYLOC(837,492,837_MYROOT,492_MYROOT)=“”
     S MYLOC(298,299,298_MYROOT,299_MYROOT)=“”
     ;
     D EN^XDRMERG(99900014,”MYLOC”)

Exclusion of Multiple Pairs For a Record—To insure that there are no unanticipated problems due to relationships between a specific record in multiple merges, prior to actually merging any data the various FROM and TO records included in the process are examined, and if one record is involved in more than one merge, all except the first pair of records involving that one are excluded from the merge. If any pairs are excluded for this reason, a mail message is generated to the individual responsible for the merge process as indicated by the DUZ.

If the following entries were included in the MYLOC array:

     MYLOC(128,247)
     MYLOC(128,536) and
     MYLOC(247,128)

Only the first of these entries (based on the numeric sorting of the array) would be permitted to remain in the merge process, while the other two pairs would be omitted). And although it may seem unlikely that someone would indicate that a record should be merged into two different locations, while another location should be merged into one that was merged away, if the pairs are selected automatically and checks are not included to prohibit such behavior, they show up. That is why the merge process does not include more than one pair with a specific record in it.

Problems Related To Data Entry While Merging

The Merge Process has been designed to combine data associated with the two records in the manner described above. On occasion, however, there are problems that cause VA FileMan to reject the data that is being entered. This may happen for a number of reasons. Some examples that have been observed include:

Clinics that had been changed so they no longer were indicated as Clinics (so they would not add to the number that people had to browse through to select a clinic), but were rejected since the input transform checked that they be clinics.
Pointer values that no longer had a valid value in the pointed to file (dangling pointers).
Fields that have input transforms that prohibit data entry.

It is possible to use a validity checker on your data prior to initiating the actual merge process (this is the action taken by merges working from the Potential Duplicate file). The data pairs are processed in a manner similar to the actual merge, so only that data in any of the files that would be merged and for which the data would be entered using VA FileMan utilities for the specific pair are checked to insure they pass the input transform. Any problems noted are incorporated into a mail message for resolution prior to attempting to merge the pair again, and the pair is removed from the data array that was passed in. Pairs that pass through this checking should not encounter any data problems while being merged.