Skip to main content
July 22, 2021
Solved

Error in primary schema after upgrading to Appian 21.2

  • July 22, 2021
  • 5 replies
  • 0 views

Hello there,

We have just upgrade Appian from 20.2 to 21.2 in Linux, standalone server.

Apparently the upgrade was going well but when we started Tomcat we saw the following error:

2021-07-22 10:06:56,796 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-00001: unique constraint (BMCOMS.USR_USERNAME_UC) violated

2021-07-22 10:06:56,820 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-00001: unique constraint (BMCOMS.USR_USERNAME_UC) violated

2021-07-22 10:06:56,829 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-00001: unique constraint (BMCOMS.USR_USERNAME_UC) violated

2021-07-22 10:06:56,964 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-00001: unique constraint (BMCOMS.USR_USERNAME_UC) violated

2021-07-22 10:06:56,992 [localhost-startStop-1] INFO com.appiancorp.process.engine.MigrateUserWithoutUuidRequest - Determining usernames without UUIDs (ad hoc users)
2021-07-22 10:06:56,999 [localhost-startStop-1] INFO com.appiancorp.process.engine.MigrateUserWithoutUuidRequest - execution has ad hoc username:
2021-07-22 10:06:56,999 [localhost-startStop-1] INFO com.appiancorp.process.engine.MigrateUserWithoutUuidRequest - execution has 1 ad hoc usernames, to be created in a deactivated state in Personalization engine.
2021-07-22 10:06:57,015 [localhost-startStop-1] INFO com.appiancorp.process.engine.MigrateUserWithoutUuidRequest - Determined there were 1 total usernames without UUIDs (ad hoc usernames), will recreate these users in deactivated state with UUIDs.
2021-07-22 10:06:57,097 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-01400: cannot insert NULL into ("BMCOMS"."USR"."USERNAME")

2021-07-22 10:06:57,099 [localhost-startStop-1] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-01400: cannot insert NULL into ("BMCOMS"."USR"."USERNAME")

2021-07-22 10:06:57,101 [localhost-startStop-1] FATAL com.appiancorp.common.web.StartupHaltingServletContextListener - Halting JVM startup: A fatal error occurred when importing system packages: Could not import system package successfully. Will retry upon restart: /apps/appian/deployment/web.war/WEB-INF/bundled-apps/system.zip
com.appiancorp.suiteapi.common.exceptions.AppianException: A fatal error occurred when importing system packages: Could not import system package successfully. Will retry upon restart: /apps/appian/deployment/web.war/WEB-INF/bundled-apps/system.zip (APNX-1-4262-001)
at com.appiancorp.suiteapi.common.exceptions.AppianRuntimeException.<init>(AppianRuntimeException.java:45)
at com.appiancorp.common.config.FatalConfigurationException.<init>(FatalConfigurationException.java:23)

It looks like there is a problem with a table of users in Oracle in the primary schema, possibly a problem with a user with a null value that was allowed in Appian 20.2 but not in Appian 21.2

I guess the only way is to raise a ticket with Appian but we would appreciate if it is a known problem that can be easily fixed.

Thanks a lot!

Best answer by jesusa310

Thanks Raghuvaran, Appian has recognized this as a bug in the product and it has been solved in the latest hotfix of Appian 21.2

5 replies

raghuvarann456
August 3, 2021

Since the primary schema is directly used by the base product. As you already mentioned, the best and the safest course of action is to get support from Appian via support case.

jesusa310AuthorAnswer
August 9, 2021

Thanks Raghuvaran, Appian has recognized this as a bug in the product and it has been solved in the latest hotfix of Appian 21.2

October 26, 2021

We have experiencing this exact same issue, we've installed the latest hotfix 21.2.595.0. We are in the progress of migrating our DEV and TEST environment. 

The only way we got Tomcat to start was to disable / re-enable the DB Null constraint before/after startup, however this resulted in multiple blank user records created in the DB. We will need a proper fix to this to progress any further with our version upgrade from 20.2 to 21.2.