I just upgraded our development environment from v7.1.1 P09 to v7.2.1 P02 (including a step up to RHES 7.8 as per installation notes requirements). After a "fresh" install in the application/database server configuration (remote database), I am getting following error when trying to run a unification:
ORA-54017: UPDATE operation disallowed on virtual columns
Digging further in the db log, I see following last entry before unification gives up:
ORA-06512: at "AVUSER.UNIF_DATA_CLEANUP", line 570 ORA-06512: at "AVUSER.UNIF_DATA_CLEANUP", line 128 ORA-06512: at "AVUSER.UNIF_DATA_CLEANUP", line 69 ORA-06512: at "AVUSER.UNFC_PROCESSOR", line 254 ORA-06512: at "AVUSER.UNFC_PROCESSOR", line 41
Finally, the last good entry just before the one above is:
BEGIN EXECUTE IMMEDIATE: Phase 2/2, Step 13/16: Part 1/7: Stage 2/3: Overlaying user data into T_MASTER_ENTERPRISE_USERS for user attribute "Supervisor" (column-name="SUPERVISOR_ID", type="USER")..
Looking at ORA-54017 explanation/resolution it simply states:
Re-issue the statment without setting values for the virtual column
This can be found at ORA-54017: UPDATE operation disallowed on virtual columns | ORA.codes
Providing that I am at the latest P02 patch available on v7.2.1, what's next? RSA engineers?
- Community Thread
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- identity unification
- Installation & Upgrade
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
Having a support case created would be the most adequate way of communication on such an issue there. If you already had done that, please state the case number here as well.
This appears to be related to an open support case 01724369.
I suspect this is a defect in the product. I cannot tell if this is a defect in the unification code itself, or a defect in data migration step that failed to update some tables correctly. My suspicion is it was a problem with migration.
Ensure you include the migration logs along with the other artifacts so we can check this as well.
This appears to be a defect in the product but its a complicated defect related to legacy data and how it interacts with the migration scripts.
We think it has something to do with incorrectly reprocessing old (very old?) unification runs.
I will update here when I have more information.
We've been using Aveksa since 4.2 days. However, this particular data is only about 2 years old as we did a green field migration from 6.8 to 7.1....