DUPLICATE RECORD (15)    FILE (1)

This file contains information about duplicate records in any file defined
the two entries were truely duplicates and change the status field
are conditional upon external SET values.  Modify this dictionary with
extreme caution.
 
Several TRIGGERs have been modified using ^%GEDIT to add MUMPS code to
the conditional logic to prevent firing during a RE-INDEX.  This was done
only for TRIGGERs that already had human readable conditional logic.
 
***** W A R N I N G *****
When you add a file to a variable pointer field FileMan deletes the
input transform so save it off before the change and restore it after
appropriately.
the change.
 
If the user changed the status to 'verified duplicate' he/she would then
be asked whether to merge RECORD1 to RECORD2 or RECORD2 to RECORD1.  The
records would then be merged accordingly.
 
This user interaction is controlled by the merge software and the dictionary
supports a merge methodology that will notify the appropriate packages
affected by the merging of the two entries and wait for their concurrence
in the two variable pointer fields; RECORD1 and RECORD2 (.01 and .02).  The
prior to actually merging the two entries.  If this approach is not desired
the software can set the appropriate fields and immediatley do the merge.
This methodology requires the two fields defined below.
 
The MERGE STATUS field is a SET where 0=not ready, 1=ready, and 2=merged.
This field would be set to 0=not ready and a bulletin would be sent to
the appropriate package users.
 
The MERGE PACKAGES field is a multiple which contains a list of packages
that are affected by the merging of entries in the subject file.  The
status of an entry in this file may be 'potential duplicate, unverified',
STATUS field of this multiple will be set to 0=not ready if the package
has the 'from' entry and does an interactive merge.  It will be set to
1=ready if the package has the 'from' entry but does an automatic merge.
It will be set to 2=no from entry if the package does not have the 'from'
entry, regardless of whether they do an interactive or automatic merge.
If the package has a merge routine in the package file the merge is
automatic.  If not, the merge is interactive.  The ERROR MESSAGE field of
this multiple will contain any errors encountered during the execution of
that packages merge routine.
 
'verified, not a duplicate', or 'verified duplicate'.
Once all entries in the MERGE PACKAGES multiple have a STATUS'=0 the MERGE
STATUS field is set to 1=ready via a TRIGGER.
 
Once the MERGE STATUS is set to 1=ready the actual merge will occur.  When
it is complete the MERGE STATUS will be set to 2=merged.  Once set to 2
most fields cannot be modified.
 
The following fields are set by TRIGGERs and are never seen by the user:
DATE FOUND, DATE VERIFIED, DATE RESOLVED, WHO CREATED, WHO VERIFIED,
and WHO CHANGED.  Also, the MERGE DIRECTION and MERGE STATUS fields will be
 
deleted by a TRIGGER if the STATUS field is modified from 'verified
duplicate' to any other status.
 
The fields LOOKUP1 and LOOKUP2 provide navigational capability from this
file to either the RECORD1 or RECORD2 entries in the file specified in
the variable pointer fields.  The field LOOKUP3 provides navigational
capability to any file that points to this file and has a DINUM
relationship.
 
A lookup on the "B" xref will get any file entry that is part of a duplicate
The envisioned sequence of events is software would identify potential
record pair because the "B" xref is set by a REGULAR xref on the .01 field
and by a MNEMONIC xref on the .02 field.
 
The "AFR" xref is used by the INPUT TRANSFORMS on the .01 and .02 field to
prevent entering a file entry that has already been merged away.
 
All xrefs that have subscripts consisting of 'RECORD^RECORD' pairs will be
'low DFN^high DFN'.
 
The "ALK" xref is short lived and contains entries that are unresolved
duplicates from a file and add an entry in this file containing the two
potential duplicates or verified duplicates that have not yet been merged.
Its form, using file 2 as an example, is ^VA(15,"ALK","DPT(",fe#1,1,fe#2,DA)
or ^VA(15,"ALK","DPT(",fe#1,2,fe#2,DA) where the 5th subscript has the
following meaning: 1=potential duplicate, 2=verified duplicate.  When the
5th subscript is a 1 there will be two "ALK" entries with the two fe#s
reversed.  When the 5th subscript is a 2 there will be only 1 "ALK" entry
and fe#s will be in the order 'from' 'to'.  Once merged the "ALK" xref
for that entry will be killed.
 
The "AMRG" xref is also short lived and contains one "AMRG" entry for
potential duplicate records and set the status field to 'potential
each entry in this file that has a MERGE STATUS of 0=not ready or
1=ready.  Once merged the "AMRG" xref for that entry will be killed.
The form of the "AMRG xref, using file 2 as an example, is
^VA(15,"AMRG","DPT(",0,DA) or ^VA(15,"AMRG","DPT(",1,DA) where the value
of the 4th subscript has the following meaning; 0=not ready, 1=ready.
 
The "AVCHG" xref is set by the WHO CHANGED field which is itself only set
when the STATUS field is changed from "V" to any other value.  If this xref
exists action needs to be taken because other packages have been notified
to merge the two entries.
duplicate, unverified'.  A user would then make the determination of whether
 
All TRIGGERs fire forward except the TRIGGER on the STATUS field of the
MERGE PACKAGES multiple which fires backward to set the MERGE STATUS field.
However, that TRIGGER has no effect on the kill side.  TRIGGER direction can
be relevent when deleting entries using ^DIK.
 
The .01 and .02 fields are 'uneditable' so entries can only be deleted from
this file using ^DIK.
 
Most TRIGGERs will not fire during a RE-INDEX of this file.  Also, many