How to Merge records

• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
When I copy a record in the Cataloging Module (edit > copy > record) and then I paste it onto another record, some of the fields in the original record, which do not exist in the copied record, are deleted while others remain.
For example, 999 is not deleted but 610 is.
What determines which fields remain and which are deleted? I understand that if the field exists in both the original and copied record will get replaced with that of the copied record.

Resolution:
For a more in depth explanation of the following see the the cataloging chapter of Guide section 16.11.1).
Fix programs linked to the MERGE routine are automatically activated when the Paste Record function is used in the Cataloging module. The MERGE routine appears in the file $data_tab/tab_fix, for example as follows:
>>grep ^MERGE $data_tab/tab_fix
MERGE fix_doc_merge OVERLAY-03
MERGE fix_doc_sort

Column two above is the program name. This means that when "paste record" is done, the programs fix_doc_merge and fix_doc_sort are run.

Regarding fix_doc_sort the explanation is:
Sorts the fields of the current record according to the order defined in the ALEPH table of codes (tab01.lng). However, within the MARC 21 5xx, 6xx and 7xx groups of fields, the order of the fields remains as they were entered by the cataloger. Note that for the sorting of the 5xx, 6xx and 7xx blocks, the 500, 600 and 700 codes must be explicitly listed in the table even if they are not used. Fields that do not have any content are deleted. In an authority library, all fields are sorted according to the order defined in the ALEPH table of codes (tab01.lng).


Regarding fix_doc_merge the explanation is:
This program merges or overlays cataloging records according to the merging program defined in the tab_merge table located in the library's tab directory. Column 3 of the tab_fix table is used to define the merging routine that matches the relevant section in the tab_merge table.

In the case quoted here, fix_doc_merge uses parameter OVERLAY-03. This is defined as follows in tab_merge:

>>grep ^OVERLAY-03 $data_tab/tab_merge
OVERLAY-03 merge_doc_overlay 03

The header to $data_tab/tab_merge states: "! merge_doc_overlay - Overlays records using the tab_merge_overlay table". The overlay table defines "Fields to retain when overlaying (merging) catalog records"

Thus, let's take a look at the tab_merge_overlay table.
Col. 1 is the merge set. Above in tab_merge 03 is defined.
Col. 2 is the Merging direction:, 1: refers to the database record and 2: refers to the record in the incoming load file
Col. 3 is the action and can be Y, N or C. (Yes, No, or Copy if not in other document, see header for more)
Col. 4 is the Tag code

In the above case we have as follows:

aleph500-16(1) HUJ01-ALEPH>>grep ^03 $data_tab/tab_merge_overlay
03 1 N #####
03 1 Y 001##
03 1 Y OWN##
03 1 Y 9####
03 2 Y #####
03 2 N 001
03 2 N 9####
03 2 C 998##


Above it is defined to keep any field beginning with 9 (in the line 03 1 Y 9####)
it is also defined to not take anything beginning with a 9 in the incoming file (03 2 N 9####)
610 is not listed here and thus deleted.

If we add the following line then 610 will not be deleted:
03 1 Y 610##