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

Description:
A job log, such as manage-01, manage-05, print-03, etc., has errors like the following:
Oracle error: update_cursor1 z30
ORA-00942: table or view does not exist
or
Oracle error: update_cursor z30
ORA-00942: table or view does not exist

Resolution:
This error indicates that the program found a ADM- or ITM-type z103 link for this bib record and, when it went to read the z30 records for this library, found that the Oracle index or the z30 table itself did not exist in this library.

Each occurrence of the message indicates one case of a bib record with an incorrect link. If there are relatively few, you may want to just ignore them. If there are thousands, check the Oracle indexes for your ADM library(s) z30(s).

You can locate/correct them as follows...

1. Run the following SQL to see what bogus/incorrect links there are in this bib library:

SQL-ABC01> select z103_lkr_library, z103_lkr_type, count(*) from z103 group by z103_lkr_library, z103_lkr_type order by z103_lkr_library, z103_lkr_type;

2. If you find values which are not legitimate libraries or legitimate z103_lkr_type's, you can use the following to get the bib record keys:
SQL-ABC01> select z103_rec_key, z103_rec_key_1 from z103 where z103_lkr_library = xxxnn' and z103_lkr_type = 'YYY';

<where "xxxnn" / "YYY" is the illegitimate library / lkr-type combination found by the first SQL>

3. Re-sending the bib records involved to the server (with util f/1/13 or the GUI Cataloging cllient) should correct the z103's.
Here are the results for one specific library:

> s+ abc01
SQL-abc01> select z103_lkr_library, z103_lkr_type, count(*) from z103 group by z103_lkr_library, z103_lkr_type order by z103_lkr_library, z103_lkr_type ;
**** Hit return to continue ****
Z103_ Z10 COUNT(*)
----- --- ----------
ABC01 ITM 21775
ABC50 ADM 3472614
ABC50 ITM 21762
ABC51 ADM 34834
ABC51 ITM 13
ABC60 EHO 1
ABC60 HOL 4235619
ABC60 ITM 1
ABC60 ND2 1
ABc50 ITM 1 <--- Note the lowercase "c".

SQL-abc01> select z103_rec_key, z103_rec_key_1 from z103 where z103_lkr_library = 'ABc50' and z103_lkr_type = 'ITM';
**** Hit return to continue ****
Z103_REC_KEY Z103_REC_KEY_1
---------------- --------------
ABC0100339891701 ABC01003398917

SQL-abc01> select z103_rec_key, z103_rec_key_1 from z103 where z103_lkr_library = 'ABC60' and z103_lkr_type = 'EHO';
**** Hit return to continue ****
Z103_REC_KEY Z103_REC_KEY_1
---------------- --------------
ABC6000428438502 ABC01003525086

SQL-abc01> select z103_rec_key, z103_rec_key_1 from z103 where z103_lkr_library = 'ABC60' and z103_lkr_type = 'ITM';
**** Hit return to continue ****
Z103_REC_KEY Z103_REC_KEY_1
---------------- --------------
ABC0100200874001 ABC01002008740


SQL-abc01>> select z103_rec_key, z103_rec_key_1 from z103 where z103_lkr_library = 'ABC60' and z103_lkr_type = 'ND2';
**** Hit return to continue ****
Z103_REC_KEY Z103_REC_KEY_1
---------------- --------------
ABC6000441223802 ABC01003618893

In another case, the bib record had fields like this:

LKR L $$aADM$$lSYS01$$b000010759 

Bib records should not and cannot have LKR type "ADM" fields. (It's ADM records which has LKR type "ADM" fields, linking them to the xxx01 bib library record.) The bib record can have LKR type "ITM" fields, but those need to point to some other record, not to the record itself.  Deleting these fields eliminated these messages.

• Article last edited: 14-Jun-2016