Skip to main content
ExLibris

Knowledge Assistant

BETA
 
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. Counting Updated BIBs

    Counting Updated BIBs

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    No headers
    • 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
    View article in the Exlibris Knowledge Center
    1. Back to top
      • Counting how many bib records were loaded in x period of time
      • Counts of overdue letters for each letter number
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 18.01
      2. contype:kba
      3. Prod:Aleph
      4. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved