GUI Clients cannot connect; "table znn in abcnn is a logical synonym"

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

Article Type: General
Product: Aleph
Product Version: 20

Description:
I've just completed the v20 upgrade (AIK, 18-19 upgrade exp, 19-20 upgrade exp) on our production server. I cannot login to the GUI client -- I'm getting the "User Name Does Not Exist" message.

I've gone through the general KB article--dlib to PWD50, util-f-4 of Z66, and no entries are displayed. However, when I view the PWD_Z66 table via the ODBC connection I see all the logins that existed in v18.

Resolution:
Looking at the /exlibris/aleph/upgrade_express_1801_1901/logs/log.20100815.073446/1000.log we see this:

Step begin 1000
A_WARNING: The table z66 in PWD50 is a logical synonym.
Step end 1000

A global grep of "is a logical synonym" in the /exlibris/aleph/upgrade_express_1801_1901/logs/log.20100815.073446/ directory shows that all of the Oracle upgrade steps are getting this message:

aleph@libprddb1(a20_2) abc50> global_grep 'is a logical synonym'

A_WARNING: The table z70 in abc50 is a logical synonym.
file above is: ./1007.log
A_WARNING: The table z108 in abc50 is a logical synonym.
file above is: ./1013.log
A_WARNING: The table z13u in abc01 is a logical synonym.
A_WARNING: The table z13u in abc30 is a logical synonym.
<etc.>

The steps which are getting this error are 1001, 1002, 1003, 1004, 1006, 1007, 1008, 1009, 1011, 1013, 1014, and 1017.
The 1001, 1005, 1010, 1012, 1015, and 1016 steps do not get the error.

As can be seen in the ./source/1nnn/implement steps for the first list above, the procedure being performed is upgrade_oracle_table.

The upgrade_oracle_table is found in the ./util/upgrade_util_ora. It shows all the steps in the first list.

The procedure which issues the "is a logical synonym" message is ./source/proc/oracle/oracle_table, which calls check_table_synonym.sql, which does this:

select SYNONYM_NAME from all_synonyms
where OWNER = '&1' and
SYNONYM_NAME = '&2';

None of the tables which are actually synonyms are involved in the ./source/1nnn/implement steps.

Solution: Insert a "set timing off" line in the /exlibris/aleph/upgrade_express_1801_1901/source/proc/oracle/check_table_synonym.sql file:

set verify off
set timing off <-- insert

With this change, the Upgrade Express no longer got the synonym error, but then got another error:

"The old table $table description does not match the expected description."

Jerry's analysis:

Each ./source/10nn step has a "znn_old_desc.dat" file. For instance, the ./upgrade_express_1801_1901/source/1011 directory has a z30_old_desc.dat file.
The ./source/proc/oracle/check_table_structure routine does:
diff -w $TMPDIR/table-current-desc.dat \
./source/$step_number/${table}_old_desc.dat >& $TMPDIR/diff_old_$table.$$
where $TMPDIR/table-current-desc.dat is the table structure before the upgrade is attempted and znn_old_desc.dat is the reference file in the source/step directory.
If different, it issues the message: "The old table $table description does not match the expected description."

<end Jerry's analysis>

[Old, outdated solution to Logical synonym error:]

* save the /exlibris/aleph/upgrade_express_1801_1901/source/proc/oracle/oracle_table as "oracle_table.beforejschange"

* changed the message in oracle_table to read "WARNING The table $oracle_table in $lib is supposedly a logical synonym, but continue anyway."

* comment out the "goto nextlib_oracle_table" immediately following, so that the proc continues.

Article last edited: 10/8/2013