Published Date: September 28th, 2026
Validated: Yes
Audience: Everyone
Products and Versions Covered:
- Jama Connect® version(s) - 9.35.x
- Self-hosted
- MSSQL 2022
Summary
During an installation or upgrade of v9.35.x, instances backed by a MSSQL database, admins may encounter an issue during oauth schema validation.
Error Upgrading - Oauth Schema Validation Failure - [authorization_entity_access_token]; found [nvarchar (Types#NVARCHAR)], but expecting [varchar(max)]
Resolution
After determining you are encountering this specific issue, the resolution will be to manually update the data type of a specific column and restart the affected oauth deployment.
Diagnosis
The first symptom will be the oauth pod failing to start due to a CrashLoopBackoff
You can check for this with kubectl get pods
Next check the available logging in the oauth pod (and possibly the core-0 pod as well). You're looking for a stacktrace with the following information:kubectl logs deploy/oauthkubectl logs sts/core
[main] ERROR o.s.boot.SpringApplication - Application run failed
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]:
[PersistenceUnit: default] Unable to build Hibernate SessionFactory;
nested exception is org.hibernate.tool.schema.spi.SchemaManagementException:
Schema-validation: wrong column type encountered in column [access_token_value] in table [authorization_entity_access_token];
found [nvarchar (Types#NVARCHAR)], but expecting [varchar(max) (Types#CLOB)]Essentially, there is a conflict in the underlying definitions between Liquibase (responsible for creating the table definition) and Hibernate (which is validating the schema).
In the affected database table (e.g. oauth.authorization_entity_access_token.access_token_value), alter the data type to match Hibernate's expected configuration:
ALTER TABLE authorization_entity_access_token ALTER COLUMN access_token_value VARCHAR(MAX);Following the database change, restart the oauth deployment from the application server:
kubectl rollout restart deploy oauthAdditional Resources
- Success Programs
- Success Catalog
- Datasheets
- Request a Solution Offering or Training from the Success Catalog
Feedback:
We welcome your input! Please sign in to leave any comments, suggestions, or ideas for improvement below.
Comments
0 comments
Please sign in to leave a comment.