Skip to main content
ExLibris
  • Subscribe by RSS
  • ExLibris Dev

    Counting Updated BIBs

    • 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
    //doorbell.io feedback widged