It's all about the answers!

Ask a question

CRJAZ1256I incompatable database issues in compatable databases


June Boston (1942538) | asked Jul 02 '15, 2:54 p.m.

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.


Comments
Donald Nong commented Jul 03 '15, 2:24 a.m.

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
Dave Evans (14812846) | answered Aug 03 '15, 2:58 p.m.

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

One other answer



permanent link
Glenn Bardwell (58621527) | answered Jul 28 '15, 1:43 p.m.
JAZZ DEVELOPER
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))
             ....






Comments
Dave Evans commented Jul 30 '15, 1:45 p.m. | edited Jul 30 '15, 1:47 p.m.

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 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.