You might see this error message when starting the Sonar client, for example via Maven (mvn sonar:sonar):
The current batch process and the configured remote server do not share the same DB configuration - Batch side: jdbc:... - Server side: check the configuration at http://.../system
The message is a bit misleading. Sonar doesn’t actually compare the database URL, it compares the ID which you can find in the database table properties under prop_key = sonar.core.id and this isn’t an ID, it’s the start time of the Sonar web server:
select * from properties where prop_key = 'sonar.core.id'
There are two reasons why there could be a mismatch:
- The database URL on the batch and the server side don’t match (just check it via the URL which the Sonar client gives you)
- There are two Sonar servers using this database. This can happen, for example, when you migrated the service from one host to another and forgot to shut down the old version properly.
Dark Views 
Hello,
I’m experiencing the same problem running Sonar plugin from Jenkins. I have checked the database URL on both sides and seems right.
Do you know how to check property sonar.core.id?. It is the same value Sonar stores in Server ID?
Regards, Carlos
To check sonar.core.id, you need to run SQL against the Sonar database. The source code is pretty confusing in this area; the variable is called SERVER_ID but it’s not the same value that you can change in the “General Settings”
Now the problem is solved. The bad thing is I don’t know exactly why.
Thanks for your help
As I said in the original posting: If the URLs are correct, the error means “there are two Sonar servers using the same database.”
Thx for your fast answer.
I queried the table properties in sonar database and get the value of sonar.core.id. Then added next line
sonar.core.id=XXX
to my sonar plugin inside Jenkins. However, I still have the same problem. Maybe I did a mistake somewhere else.
This was a great help. I had two Sonar WARs pointing at the same database (one was a sandbox, one was ‘production’).
The trick was to shut them both down, then only restart the ‘production’ instance because Sonar resets the sonar.core.id on startup.
FWIW you can get the server’s id via REST:
http://server:port/sonar/api/server
It has to match the one in the database for Sonar to work.
Thanks! In my case “select * from properties where prop_key = ‘sonar.core.id’ returned ID different from the one returned by “/api/server”. The solution was to restart Sonar, oh my God.