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

Description:
In our test database, I loaded about 5000 Authority records which in turn generated about 140,000 indexing requests in ABC01 to run through ue_01. I know that not all will actually make changes to ABC01 records, but some did.

Is there a way to determine how many records were actually changed through the ue_01 indexing? The first date I came across was in Z13. Is this the best way to get such a count? Or might there be a more accurate or appropriate place to determine this information?

Resolution:
The presence of a "BATCH-UPD" field, such as the following, indicates that ue_01 (or p_manage_21) has processed this record:

CAT L $$aBATCH-UPD$$b00$$c20080229$$lABC01$$h1619

but it does *not* indicate that any change was actually made to the record.

The presence of 'Update doc : Y' in the run_e_08 log indicates that some update *may* have been made; if it's ''Update doc: N', then *no* BIB update could have occurred:

>> grep -c 'Update doc : N' run_e_08.9954
534
>> grep -c 'Update doc : Y' run_e_08.9954
14222

z13_update_date includes not only update requests generated by ue_08 but all update requests. It does *not* mean that any change was actually made to an indexable field in the BIB record.

SQL> select count(*) from z13 where z13_update_date > '20080229%';
COUNT(*)
----------
21646

The Z07 records which ue_01 processes are written either because of an update to a BIB record (online or batch) or by ue_08 (in regard to potential flipping of a BIB record heading field).

ue_01 updates the Z13. The update_short_docx program which performs this update does not know whether there has been an update to the fields included in the Z13 -- or if there has been any change to the bib at all. It recreates the Z13 from the Z00 *regardless* ( -- and includes a new z13_update_date.)

To summarize:
* ue_01 can add a "CAT L $$aBATCH-UPD ..." field to a BIB record even when no actual change occurs to the record.
* ue_01 updates the Z13 in every case.

There *is* a facility which detects actual changes to BIB records: the ue_21 publishing daemon -- used in connection with Primo -- which writes z00p records. (The Z00P is normally located in the $usr_library.) ue_21 compares the existing Z00P to the current Z00 and writes a new Z00P (with a z00p_status of "UPDATED") only when they are different.

If you have the Z00P, this SQL could be used:

SQL>> select count(*) from z00p where z00p_status = "UPDATED" and substr (z00p_timestamp,1,8) > 'yyyymmdd';

• Article last edited: 10/8/2013