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

    After upgrade, items/orders attaching to wrong bib record

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

    Description:
    When a new record is brought in through OCLC, an older order and/or an older item record are attaching themselves to the record.

    Ex. A record for "Full Metal Apache" (1746615) was brought in this morning at 10:56 -- an item attached itself to this record which had previously been attached to "community level socio-economic context of fuelwood use" (1746588) which was created last thursday 8/17 (the list of catalogers shows a batch-upd of 10:57 (no user name).

    We have had the same problem with bringing in a new record and then having an older order attach itself to the new record.

    Resolution:
    At the time of the original upgrade, you had this in 14.2:

    abc01 last-doc-number 1746567
    abc50 last-doc-number 1777865

    These were on 14.2 and were brought to 16.02 as part of the loaded z52's for abc01 and abc50.

    Between the original load and Aug. 18 6 pm, bib records 174568 - 1746597 were created, with the associated ADM records 1777866 - 1777895.

    The circ reload brought in an updated abc50 z52 from 14.2. (This is needed, for instance, to get the correct last-loan-number , which has been incremented by the ongoing circ activity.) But it also brought the old abc50 last-doc-number from 14.2: 1777865.

    So, when bib records were created in prod 16.02, the system tried to create ADM records beginning, once again, with 1777866.

    The system uses this logic:
    Try to create an ADM record with the same key as the bib record;
    if an ADM record with this key already exists,
    use the ADM library last-doc-number for the new ADM record key; but,
    if an ADM record with this number already exists, then
    use that ADM record as the ADM record for this new bib.

    It seems to me that this borders on being a bug -- but it gets tricky -- what key *is* it going to use in such a case(?)...

    When it reached ADM 1777896, it was beyond the range of the existing ADM's and the problem ceased from that point on.

    In an upgrade, if bib and ADM records have been created on the target machine during the period preceding the circ reload, then before doing the circ reload, you need to note the last-doc-number and, after the load of the z52, update the last-doc-number to the number noted.

    Additional Information

    faq


    • Article last edited: 10/8/2013
    //doorbell.io feedback widged