Database connection cannot be established. Please check database status and JDBC settings

Hi team,

We’re facing an upgrade blocker on SonarQube Community Build 25.12.0.117093 when running on Azure SQL.

Environment:

  • SonarQube: Community Build 25.12.0.117093
  • Deployment: Azure App Service (container-based)
  • Database: Azure SQL
  • DB collation: SQL_Latin1_General_CP1_CS_AS (as required)

Issue:

I have tried to update to latest version, but get an error after the Db migration Database connection cannot be established. Please check database status and JDBC settings
During startup, SonarQube correctly connects to the database, but fails during the manual DB migration step (/setup).

Error:
Migration step #202506016 fails:
“Add index based on ‘resource_id’ and ‘resource_type’ to ‘jira_work_items_resources’ table”

Root error:
Cannot resolve collation conflict between
SQL_Latin1_General_CP1_CI_AS and SQL_Latin1_General_CP1_CS_AS
occurring in UNION ALL operator during metadata/index lookup.

Observations:

  • DB connection works (HikariPool initialized successfully)
  • Failure occurs when SonarQube queries index metadata
  • Looks like a mixed collation issue triggered by the migration logic itself

Question:
Is this a known issue with 25.12.x on SQL Server/Azure SQL?
Is there a recommended workaround other than rebuilding the database?

Thanks!

1 Like

Hello,

same problem on developer 2025.6. We solved by downgrading the jdbc driver back to 13.2.0

Hello, we are investigating the issue, I’ll keep you posted.

1 Like

Ok, I think we found that the root cause.
In SQ 2025.6 we upgraded Microsoft JDBC driver for SQL Server from version 13.2.0 to 13.2.1.
The newer driver version introduced a change which unfortunately exposes a collation conflict in certain Azure SQL configurations.
The error occurs when there’s a mismatch between your Azure SQL Server’s collation and your database collation. While SQ requires the db to use a case-sensitive collation (SQL_Latin1_General_CP1_CS_AS) Azure SQL Server are created with a default collation which is case-insesitive (SQL_Latin1_General_CP1_CI_AS). The mismatch was previously harmless, but the new JDBC driver internal query now trigger a conflict during db migrations.

We will release a bug fix that reverts the JDBC driver to 13.2.0, which does not have this issue.

In the meantime, you can work around this issue by replacing the JDBC driver with the previous version.

Thanks a lot for reporting the issue!

1 Like

Thanks for the clarification.

We are running SonarQube using the official Docker image (sonarqube:latest) on Azure App Service, backed by Azure SQL Database.

The issue appeared after sonarqube:latest pulled 25.11.0.114957-community, which includes the JDBC driver upgrade from 13.2.0 → 13.2.1. During startup, the database migration fails due to the collation mismatch on Azure SQL, leaving the database in a partially upgraded state and preventing SonarQube from starting.

This setup was working correctly with earlier SonarQube versions that bundled JDBC 13.2.0, and we did not encounter this issue prior to the upgrade.

We understand a fix is planned to revert the JDBC driver. In the meantime, could you please confirm:

  • Which Docker image tag is safe to use that still bundles JDBC 13.2.0

  • Whether lts-community is affected or recommended as a workaround

  • Whether there is a supported way to pin or override the JDBC driver version when using the official Docker image, especially in managed environments like Azure App Service

Additionally, do you have an estimated timeline for the release that includes the JDBC revert?

Thanks for your support and for investigating this issue.

Any updates on when fix will be released?

3 Likes

Reporting another instance of this, we are running using Azure SQL with the official Docker images and seeing the problem.

Happy new year,
for me downgrading the SQL driver to 13.2.0 on my Azure SQL database did not solve the problem for CE 2025.11 → CE 2025.12 migration:

...
2026.01.02 14:50:50 INFO  web
[o.s.s.p.d.m.DatabaseMigrationImpl] Starting DB Migration and container restart
2026.01.02 14:50:50 INFO  web
[DbMigrations] Executing 16 DB migrations…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 1/16 #202506008 ‘Create ‘integration_configs’ table’…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 1/16 #202506008 ‘Create ‘integration_configs’ table’: success | time=78ms
2026.01.02 14:50:50 INFO  web
[DbMigrations] 2/16 #202506009 ‘Create ‘slack_subscriptions’ table’…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 2/16 #202506009 ‘Create ‘slack_subscriptions’ table’: success | time=76ms
2026.01.02 14:50:50 INFO  web
[DbMigrations] 3/16 #202506010 ‘Create ‘slack_workspaces’ table’…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 3/16 #202506010 ‘Create ‘slack_workspaces’ table’: success | time=70ms
2026.01.02 14:50:50 INFO  web
[DbMigrations] 4/16 #202506011 ‘Create ‘user_bindings’ table’…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 4/16 #202506011 ‘Create ‘user_bindings’ table’: success | time=48ms
2026.01.02 14:50:50 INFO  web
[DbMigrations] 5/16 #202506012 ‘Create ‘user_bindings_slack’ table’…
2026.01.02 14:50:50 INFO  web
[DbMigrations] 5/16 #202506012 ‘Create ‘user_bindings_slack’ table’: success | time=49ms
2026.01.02 14:50:50 INFO  web
[DbMigrations] 6/16 #202506015 ‘Add ‘created_by’ column to ‘jira_work_items’ table’…
2026.01.02 14:50:51 INFO  web
[DbMigrations] 6/16 #202506015 ‘Add ‘created_by’ column to ‘jira_work_items’ table’: success | time=288ms
2026.01.02 14:50:51 INFO  web
[DbMigrations] 7/16 #202506016 ‘Add index based on ‘resource_id’ and ‘resource_type’ to ‘jira_work_items_resources’ table’…
2026.01.02 14:50:51 ERROR web
[DbMigrations] 7/16 #202506016 ‘Add index based on ‘resource_id’ and ‘resource_type’ to ‘jira_work_items_resources’ table’: failure | time=310ms
2026.01.02 14:50:51 ERROR web
[DbMigrations] Executed 6/16 DB migrations: failure | time=928ms
2026.01.02 14:50:51 ERROR web
[o.s.s.p.d.m.DatabaseMigrationImpl] DB migration failed | time=984ms
2026.01.02 14:50:51 ERROR web
[o.s.s.p.d.m.DatabaseMigrationImpl] DB migration ended with an exception
org.sonar.server.platform.db.migration.step.MigrationStepExecutionException: Execution of migration step #202506016 ‘Add index based on ‘resource_id’ and ‘resource_type’ to ‘jira_work_items_resources’ table’ failed
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:105)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:89)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:66)
at org.sonar.server.platform.db.migration.engine.MigrationEngineImpl.execute(MigrationEngineImpl.java:55)
at org.sonar.server.platform.db.migration.DatabaseMigrationImpl.doUpgradeDb(DatabaseMigrationImpl.java:106)
at org.sonar.server.platform.db.migration.DatabaseMigrationImpl.doDatabaseMigration(DatabaseMigrationImpl.java:81)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.IllegalStateException: Can not check that table jira_work_items_resources exists
at org.sonar.db.DatabaseUtils.wrapSqlException(DatabaseUtils.java:471)
at org.sonar.db.DatabaseUtils.getIndex(DatabaseUtils.java:374)
at org.sonar.db.DatabaseUtils.findIndex(DatabaseUtils.java:361)
at org.sonar.db.DatabaseUtils.findIndex(DatabaseUtils.java:347)
at org.sonar.db.DatabaseUtils.doIndexExistsIgnoreIndexCase(DatabaseUtils.java:326)
at org.sonar.db.DatabaseUtils.indexExistsIgnoreCase(DatabaseUtils.java:320)
at org.sonar.server.platform.db.migration.step.CreateNonUniqueIndexOnColumns.execute(CreateNonUniqueIndexOnColumns.java:44)
at org.sonar.server.platform.db.migration.step.DdlChange.execute(DdlChange.java:45)
at org.sonar.server.platform.db.migration.step.MigrationStepsExecutorImpl.execute(MigrationStepsExecutorImpl.java:101)
… 8 common frames omitted
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: VIEW DATABASE PERFORMANCE STATE permission denied in database ‘SONARDEV_2026-01-01T14-43Z’.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:278)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1788)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:688)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:607)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7825)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:4828)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:321)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:253)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(SQLServerPreparedStatement.java:521)
at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getIndexInfo(SQLServerDatabaseMetaData.java:1414)
at com.zaxxer.hikari.pool.ProxyDatabaseMetaData.getIndexInfo(ProxyDatabaseMetaData.java:229)
at com.zaxxer.hikari.pool.HikariProxyDatabaseMetaData.getIndexInfo(HikariProxyDatabaseMetaData.java)
at org.sonar.db.DatabaseUtils.getIndex(DatabaseUtils.java:365)
… 15 common frames omitted


Any idea on how to fix?

I’m using 25.12.0.117093 (community) and still having the same issue on the jira_work_items_resources table too

After adding the missing permission with
GRANT VIEW DATABASE PERFORMANCE STATE TO <sonar-db-user>;
I was able to to run the 2025.12 db update.

The fix has been released in SonarQube Community Build 26.1 and SonarQube Server 2026.1.

Please update to the latest versions on Download SonarQube.

1 Like

But what about community? The docker tags for 6.1 etc are 12 days ago which corresponds with the release but the community version is last built 25 days ago

1 Like

My mistake, the SQ CB 26.1 binaries have not been released yet. They should be released within the next day or two. Once that is done, the Docker tags will be updated.

2 Likes

@PsyVision : SQ CB 26.1 docker tags are ready! sonarqube - Official Image | Docker Hub

1 Like

Thank you @Joe - Back up and running now!

2 Likes