Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    ADM record auto-created when pushing from ITEMS to BIB in multi-ADM environment

    • Article Type: General
    • Product: Aleph
    • Product Version: 20, 21, 22, 23

    Description:
    Months ago via an ARC SI I realized we had multiple ADM records linked to the same BIB records in our ALEPH data. When I finally got around to trying to find out why, I was amazed to find that these "extra" ADM records appear to be created during what I would consider to be normal work/workflow operations.

    We are a multi-ADM site with a shared BIB library. We also have a Depository ADM (DEP50). When we search our own BIB records each of us sees DEP bibs too.

    The problem is that, if a DEP bib turns up in a search of any kind and is pushed to ITEMS, an ADM record is automatically created for whatever ADM the GUI is connected to via ALEPH-->Select ADM Library-->XXX50. During the normal course of working in ALEPH, that ADM library would be our own, e.g. ABC50. So, if one of us happens upon a DEP50 BIB and pushes it to ITEMS, then we automatically get a "new" (and extraneous) ABC50 ADM record.

    The ultimate problem is that these extraneous ADM records cause the bib info to be pushed to ARC data, thus skewing statistical query results.

    Is there some way we can prevent this from happening? Is there a faulty table or permission setting at work here?

    Resolution:
    Setting the xxx50 tab100 ADM-OWN-CHECK (which has a default of "N") to "Y" can prevent this :

    !# ADM-OWN-CHECK
    !# Values:Y N Default: N
    !# Type: Text; Max Length: 01
    !# tab100 of library: Yes; tab100_<server_type>: No.
    !
    ! Y = OWN on the bibliographic record used to difference the
    ! ADM libraries, then check the user against the OWN when
    ! pushing BIB record into ADM environment.
    ! N = The bibliographic OWN field is not checked.


    Version 16.02 rep_change 199 says: "The development is done to solve the problem of creation of orphan ADM records."


    • Article last edited: 10/8/2013