Error during installation of CA SDM 17.4

[Domingo Andres]

Hi,
we are trying to upgrade our environments from CA SDM 17.3.0.22 to CA SDM 17.4. As the environments are being used, this is what we have done to check the 'new' CA SDM 17.4 version:
-Create a new environment (Windows Server 2022, Oracle 19)
-Install CA SDM 17.3.0
-Install CA SDM 17.3.0.22 rollup
-Install T5UG519 and T5UG528 patches 
-Import mdb from our PRO environment (following steps from Broadcomm. PRO and the new environment are on the same version 17.3.0.22)
-Install CA SDM 17.4 (Installation fails)

When we try to install CA SDM 17.4 version, the installer fails at the first step 'Configuration of the common tables' and on the 'install_CADB.log' file appears the next error:

2024-08-12 16:44:34,070 INFO - MDBTools_0116I - Reconciling the database with the MDB schema information
2024-08-12 16:44:35,023 INFO - MDBTools_0319I - Reconciliation detected that trigger 't_usp_record_lock.xml' is missing from the database
2024-08-12 16:44:36,883 INFO - MDBTools_0104I - Total time: 0H:0M:6S.

The funny thing is that on the 'mdb_schema_information' table, a record with ''t_usp_record_lock.xml' filename exists. We checked the trigger 'usp_record_lock_trigger' and also the exists on the database.

The problem appears if we try to install CA SDM 17.4 after migrating/importing data from other environment, in this case our PRO environment. If we try to install CA SDM 17.4 on a clean installation of CA SDM 17.3.0.22, the installer works correctly.

¿Does anybody suffered from something similar? We opened a case to Broadcomm a couple of weeks ago but they haven't found a solution yet.

Greetings.

[Domingo Andres]

Hi,
In order to install CA SDM 17.4 in our environment (from a 17.3.0.22 installation), we had to increase the size of the TABLE_NAME column in the TEMP_MDBTOOLS_PERMISSIONS table. After that, the installer worked.

ALTER TABLE TEMP_MDBTOOLS_PERMISSIONS
MODIFY TABLE_NAME VARCHAR2(35 BYTE);

Once we finished the upgrade, we restored the size of the column to its original value. (30 BYTE).

Hope it helps.
Greetings.

[Hemalatha Simhadri]

Hi Andres,

The log you have marked in yello is a INFO level message and it should not block the installation.

Can you please check if there are any other errors in the log. 

Also share the support case number.

Thanks & Regards,

Hema.

[Domingo Andres]

Hi Hema.
Thanks for your answer.
The log installation folder was attached to the case and sent to Broadcom. They checked them and didn't find anything apart from this.
The case number is: Case#35610464
Greetings.

[Sebastian Nagy]

Hi Andres,

I tend to agree with Hema that this message is a not what triggers the issue, but there is some exception that is not captured.

The trigger seems to be captured by running the following query with no trigger name `SELECT TRIGGER_NAME FROM USER_TRIGGERS ORDER BY TABLE_NAME, TRIGGER_NAME` .

In the step that it fails, t_usp_record_lock.xml should not even exist. This is a SDM specific trigger.

Can you confirm that you see t_usp_record_lock.xml in mdb_schema_information in both MDBs, backup/restore & clean install?

In my MDB I don't have that row.

Regards,

Sebastian

[Domingo Andres]

Hi Sebastian,
thanks for your answer.
I checked all the snapshots I have of my virtual machine and the record with filename 't_usp_record_lock.xml' appears in all of them in the mdb_schema_information table.

-17.3.0.22 clean installation

-17.3.0.22 with imported data

-17.4 clean installation

Greetings.

[Sebastian Nagy]

Hi Andres,

The next check would be  to check:

SELECT TRIGGER_NAME FROM USER_TRIGGERS ORDER BY TABLE_NAME, TRIGGER_NAME

and

select * from mdb_schema_information

and compare the output between the 3 servers, you can ignore the date/time fields.

Something is different, we need to figure out what. But I would recommend to continue to work via support for it, I don't think community is the best place for this type of questions. It exposes to much private information.

Regards,

Sebastian

[Domingo Andres]

Hi Sebastian,

we found something while generating debug logs during the installation of CA SDM 17.4. 
An oracle error appears because It seems it's trying to insert some data in a column that do not fit.

2024-08-30 11:36:26,655 DEBUG - Exception Msg:  ORA-12899: el valor es demasiado grande para la columna "MDBADMIN"."TEMP_MDBTOOLS_PERMISSIONS"."TABLE_NAME" (real: 31, máximo: 30)

The strange thing is that we checked the columns size in that table (TEMP_MDBTOOLS_PERMISSIONS) in different versions of CA SDM (17.3.0.22 clean, 17.3.0.22 imported data, 17.4 clean) and the columns size are exactly the same.

Anyway, we sent this info to ca support and we'll keep invistigating the problem through the case. If we find the root cause, I'll post it here in case it helps other users.

Greetings and thanks for your help.