Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

CRJAZ1256I incompatable database issues in compatable databases

We had our database team upgrade a staging environment's SQL Server 2008 to SQL Server 2012.  It's just a Tomcat install of 4.0.6 so we installed 5.0.2 with Tomcat on a new Windows Server 2012 VM, copied over the old JazzTeamServer directory, and proceeded with the upgrade.

The old jdbc driver seemed to have compatibility issues, so we got the latest copy of SQLJDBC4.jar from Microsoft.  At this point we've tried all the different versions.  No matter what, we end up having the above error somewhere in the logs, and Step 1 of the repotools migration fails.  The following support page even shows the error we have:

http://www-01.ibm.com/support/docview.wss?uid=swg21680101

I note on the support page it indicates the problem happens "on Microsoft SQL Server 2012" while the solution indicates we must upgrade to 2012.  We are already on 2012; why would this error be occurring?

The specific error is CRJAZ1256I SQL Server version 11.x or 12.x is required but version
"10.50.2500" was detected instead.

We put the overrides into the ccm/ and jts/repository.config files, and while jts successfully ran its steps (though with a few indicators that the SQL was wrong) ccm will not get very far.  Was it a mistake to upgrade the database in-place?  Should a repotools import/export be performed instead?  We are not certain why this error is occurring.

0 votes

Comments

Do you have other means to verify the version of SQL Server? Something like this:
http://stackoverflow.com/questions/26233443/identify-sql-server-version-using-jdbc


Accepted answer

Permanent link

It appears that the upgrade scripts do not properly use the connection string as it is specified in the teamserver.properties file. On a hunch, we turned off a 2008 SQL Server instance which was running on the same server using port 1433, and we reconfigured our databases to use port 1433. The scripts then worked.

This is apparently a defect with the scripts which we were able to overcome by modifying our database connection properties.

June Boston selected this answer as the correct answer

0 votes


One other answer

Permanent link
The code that RTC uses to determine the version is similar to the one described above.
public void assertRequiredVersion(Connection connection) throws TeamRepositoryException, SQLException {
        ...
        DatabaseMetaData metaData = connection.getMetaData();
        String productVersion = metaData.getDatabaseProductVersion();
        String productName = metaData.getDatabaseProductName();
        ...
        int v = Integer.valueOf(productVersion.substring(0, productVersion.indexOf('.')));
        if ((v != 11)&&(v !=12))
             ....





0 votes

Comments

Is it possible that not all of the connection properties from the teamserver.properties file are being captured and used? We have a 2008 instance which is running on the same server as our 2012 database. teamserver.properties has a port # AND an instance name... but if the script is not validating the exact database, it could be contacting a different database on the same server. I'll ask today to see if we can turn off the 2008 instance today and see how it goes. Our 2012 port # is not 1433, but our 2008 instance IS using that port #.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 267
× 2

Question asked: Jul 02 '15, 2:54 p.m.

Question was seen: 3,103 times

Last updated: Aug 03 '15, 2:58 p.m.

Confirmation Cancel Confirm