Holdings links pointing to incorrect bib records

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 19.01

Description:
Yesterday I loaded records with p_manage_18 followed by p_manage_50. All appeared well. Later in the day I received reports that the holdings records appeared as if they were linked to different, i.e. wrong bib records. Last night I ran a test batch and all appeared well for the several minutes I was rechecking. However, I just checked the records and the holdings links have disappeared from the left hand display. Screen shots are attached. The springer_test.doc includes shots from last night and tonight for the first and last records of my test set. The second set (springer_error_0504.doc) are screen shots of the different link views.

The short version. I load a bib record assigned sysno 5450543 with manage_18. I create adm, holdings, and items using p_manage_50 using the bib sysno set. It created ADM 5604708 and holdings records 8244571 and 8244572. Screen shots show they were indeed created. Today, I see no holdings records displayed in the left pane, although the ADM is still there. If I search the ADM and see the item records with the correct bib and adm numbers displaying in the title bar. However, if I search the holdings record numbers in ABC60 I am taken to an entirely different holdings record than expected with the wrong bib linker.

Initially, I thought that the problem was related to batch load as no one reported an issue with manually created records. However, two reports came in today reporting the same mysterious behavior occurring with manually-created recs.

Resolution:
I found two things:

1. SQL-ABC60> select max(z00_doc_number) from z00;

gave a value of "08244420 ". Note that there is just one zero preceding the 8. It seems that "008244420" was intended, but the initial "0" was left off.

2. The abc60 util g/2 last-doc-number was 008244425 -- even though there were many abc60 doc records with higher keys.

The abc60 doc record 08244420 had been logically deleted (and util f/3/12 showed that there were no links). I physically deleted it. The select max(z00_doc_number) SQL then gave a value of 008244889. I changed the last-doc-number in util g/2 to this value.

After this change, the problem of new bib/hol records having bad linkages was solved, but the previous existing ones needed to then be cleaned up individually.

We don't know how the "08244420 " record was created. It seems that it is *not* possible to do this in the GUI. If you were batch loading HOL records with p_manage_18 in Update mode, a record could have this bad key -- but in this case, though p_manage_18 was used to create the abc01 doc record, the xxx60 doc records were created by p_manage_50, which uses the abc60 util g/2 last-doc-number to assign the HOL key.

Article last edited: 10/8/2013