Merge File Entries    ICR (2365)

The entry point EN^XDRMERG provides for merging of
one or more pairs of records in a specified file.  This entry point takes two
(2) arguments, the file number (a numeric value) and a closed reference to the
location where the program will find an array with subscripts indicating the
record pairs to be merged (a text value).  There can be either two or four
subscripts in the data array as described below. the command

D EN^XDRMERG(999000014,"MYLOC")

would result in record pairs specified as subscripts in the array MYLOC to be
merged in a hypotheical file 999000014. The array MYLOC might have been set up
prior to this call in the following manner (or any equivalent way) where the
subsripts 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 will occur without a specific record of the entries prior
to the merge (The internal entry numbers merged would be recorded under the
file number in file 15.3) An alternative is a four subscript format for the
data array which 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 premerge 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 file (file 15.4). For the above example data [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 ommitted
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 aren't included to prohibit such
behavior, they will show up.  That is why the merge process won't 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 which cause VA File Manager to reject the data that is being entered.
This may happen for a number of reasons.  Some that have been observed were:
Clinics which had been changed so they no longer were indicated as Clinics (so
they wouldn't 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 which would be
merged and for which the data would be entered using VA File Manager utilities
for the specific pair are checked to insure they will 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 which pass through this
checking should not encounter any data problems while being merged.

This entry point is used to restart a merge which has
been stopped.  The information necessary for restarting may be viewed using
the CHKLOCAL entry point in XDRMERG2 (see LOCAL MERGE STATUS).