We have recently upgraded to Sonar 5.3 from 4.4.1 and seen duplicate key issue with one of our projects. I checked the collation and found database server and database to be case insensitive and column to be case sensitive. Should we change collation on the database to "Latin1_General_CS_AS" ? Changing the collation on the server is bit difficult but we can try with database.
SELECT SERVERPROPERTY('COLLATION')
Output: Latin1_General_CI_AS
SELECT DATABASEPROPERTYEX('<SonarDatabaseName>', 'Collation') SQLCollation;
Output: Latin1_General_CI_AS
For the column, it is "Laitn1_General_CS_AS"
Error in sonar log. I did see a duplicate key in the table but not sure if this is due to collation as reported here Duplicate key error with SonarQube 5.2:
ERROR [o.s.s.c.t.CeWorkerCallableImpl] Failed to execute task AVM28yZdM8YcgYQ_GJuI
org.sonar.server.computation.component.VisitException: Visit failed for Component
.
.
### Error updating database. Cause: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot insert duplicate key row in object 'dbo.projects' with unique index 'projects_kee'.
Thanks in advance.
Case sensitivity is a requirement, so yes you really need to change the collation of this database (putting it case-sensitive (CS) and accent-sensitive (AS)).
Related
Today I had to rebuild our BugZilla installation. It has been painful, mainly because I unintentionally incurred an upgrade from MySQL 5.7 to MySQL 8.0. Now BugZilla is reporting an SQL syntax error. In an attempt to debug this, I connected directly to the database using the MySQl client and ran the following query:
SELECT * FROM groups;
This results in the error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups' at line 1
The same query works for any other table, just not "groups". I am exhausted and have no energy left to solve this. I am guessing that MySQL 8.0 introduced "GROUPS" as a keyword. I would appreciate some help.
Upon investigation it turns out that MySQL 8.0 has indeed introduced "groups" as a keyword, and BugZilla needs to be modified to quote the table name in all places. Unfortunately the database code is shared among many different types of database which all use different characters to quote table names.
My final solution was to switch to using PostgreSQL.
We are using Oracle 12c database with Entity Framework 6.1. We are using code first model to connect to Oracle database.
Although the data is saved successfully while reading the data it gives and error on a column which has a foreign key dependency on another table.
The error says:
"Extent1"."COLUMN_NAME": invalid identifier
I have checked the column name and the relationship between the table and the foreign key id.
Please suggest if anyone has faced the same issue.
regards,
A
I am trying to install Sonarqube 5.3 using an Oracle 12.1.0.2.0 database.
Oracle user is created with all permission granted (grant all) and "revoke select any" options.
Sonar is started with "./sonar.sh start" but the initial schema creation fails AFTER table creation ON insert to table "GROUPS":
2016.01.15 09:42:25 ERROR web[jruby.rack] initialization failed
org.jruby.rack.RackInitializationException: An error has occurred, all later migrations canceled:
ActiveRecord::JDBCError: ORA-00904: "VERSION": invalid identifier
: INSERT INTO groups (name, description, created_at, updated_at, displayname, created, lastmodified, version, id) VALUES('sonar-administrators', 'System administrators', TO_TIMESTAMP('2016-01-15 09:42:25:478000','YYYY-MM-DD HH24:MI:SS:FF6
'), TO_TIMESTAMP('2016-01-15 09:42:25:478000','YYYY-MM-DD HH24:MI:SS:FF6'), NULL, NULL, NULL, 0, ?)
Compared the table structure with the statement I noticed that not all columns have been created: Columns DISPLAYNAME, CREATED, LASTMODIFIED, VERSION are missing!
Why are these not created?
If I create them manually, sonar fails to start afterwards. Is there any way to re-init the initial data?
Using sonars embedded database works fine.
Any ideas?
Problem solved!
It seems database configuration and permissions in combination with public synonyms on our database caused this issue.
The problem has been solved by proceeding the following steps:
wipe out partly generated schema including all containing objects
install Sonarqube 5.3 on a newly/clean Oracle XE 11 database and create basic configuration
stop Sonarqube & export database schema
import database schema on Oracle 12 database
After starting up Sonarqube I realized a problem with Oracle JDBC driver 12.1.0.1 producing a NullPointerException while starting.
Basically this is a bug in the driver itself and already fixed by Oracle -> use ojdbc-driver 12.1.0.2 to fix this issue!
Hope this might help some other people with similar problems.
After installing SONAR 3.7.3 I received the following error on startup: "o.s.s.p.DatabaseServerCompatibility Database must be upgraded. Please browse /setup"
I then followed instructions to upgrade the databse by navigating to http://:/setup. However, when I click update databse I get the following error
The migration failed: An error has occurred, all later migrations canceled: ActiveRecord::JDBCError: ORA-01430: column being added already exists in table : ALTER TABLE reviews ADD manual_severity NUMBER(1).
Please check the logs.
I can see, as the message suggests that the table reviews already exist and it already contains the column manual_severity, so I'm not sure why its trying to re-add it.
Any ideas?
I would use a backup of the database schema and start the process again from the beginning.
If you don't have a backup, I cannot see any other way than to delete the column in your schema and try to migrate the database again, but you might find a lot of errors of this kind and have to repeat this operation some times. Also, you will never be sure that your DB is Ok.
I have a web app hosted on BEA Weblogic 10.x with an Oracle 10g database backend.
It works perfectly with one database, but when we make a clone of it and try to use a different WebLogic and Oracle instance we are getting this error:
ERROR - Problem initializing invocation tracking - disabling
tracking xxxxclass.BadTableMappingException: Database column
xxxxPeriodEnding in database yyyyyyy, table zzzzzzz has an
unknown type: JDBC Type 91.
We get it every time we do a query that involves a column of type DATE. There was no ORA-XXXX code in the message.
I can access the database using SQL*Plus using the same access and do selects and updates on the same tables with no errors.
The answer to this question is not just a simple description of what a type 91 error is (although that will help) but what could be causing this given the circumstances described above.
I am using ojdbc14.jar for JDBC on both instances of weblogic.
I have no idea about the error, but have you considered the jdbc jar version and more importantly if the oracle DB needs to be updated.
I faced very weird problems with oracle, and struggled for a while to find at the end that installing some patches for oracle would solve the problem.
Set oracle.jdbc.V8Compatible=true.
This remaps the oracle DATE type to a DATETIME time in JDBC. This parameter was missing on the new Weblogic server.