cancel
Showing results for 
Search instead for 
Did you mean: 

What to do when you get the message *.jar build does not match the shared object build.

Former Member
16,894

I am going to ask the documentation team to add a trouble shooting note containing the information below. As a result, this "question" is not really a question but rather a preemptive doc note.


Over the past several years, there has been the odd question on the newsgroups where an SQL Anywhere user will find that after applying an EBF, their JDBC applications suddenly stops working and instead they get a message similar to the following when trying to run their JDBC application:

The sajdbc.jar build does not match the shared object build.

This problem usually occurs because the use either had DBISQL, Sybase Central, the fast launchers or their own JDBC application still running when the EBF was applied. The JAVA VM locks any dlls or shared objects that are loaded by it, but it does not lock the jars. As a result, applying the EBF will quite often update the sajdbc, sajdbc4, jodbc and/or jodbc4 jars but not the accompanying dbjdbc and/or dbjodbc dll or shared object. Hence, when the JDBC application is restarted, the jdbc jar will suddenly be out of sync with the accompanying dll or shared object and the above message is therefore returned.

The easiest thing to do at this point is to shut down all JDBC based applications and reapply the EBF. If reapplying the EBF does not resolve the problem, then the following additional trouble shooting information might help.

To trouble shoot the problem, users should start by ensuring that on Windows machines, the dbjdbc?.dll and dbjodbc?.dll files got properly updated by the EBF installer while on UNIX machines, users need to check the libdbjdbc?.so.1 and libdbjodbc?.so.1 shared objects. Note that when checking the various dlls and shared objects, it is important to check the dlls and shared objects that match the bitness of the JAVA VM (not the bitness of the SQL Anwhere server).

If the dlls and shared objects seem to have been properly updated by the EBF installer, then check to make sure you do not have multiple copies of the dlls and shared objects on your system. Quite often users will copy the dlls or shared objects to extensions folders of the JAVA VM in order to avoid the JAVA restriction of not allowing dlls and shared objects to be loaded within multiple class loaders.

If you are sure the dlls and shared objects were properly updated by the EBF installer, and you do not have multiple copies of the dlls and shared objects on your system, then check to make sure the various jar files were properly updated. To check each jar file, execute the following and ensure that the SQL Anywhere version and build number reported by the jar file matches the SQL Anywhere version and build number of the EBF that you installed.

To check sajdbc.jar, execute:

java -cp sajdbc.jar sybase.jdbc.sqlanywhere.IBuildNum

To check sajdbc4.jar, execute:

java -cp sajdbc4.jar sybase.jdbc4.sqlanywhere.IBuildNum

To check jodbc.jar, execute:

java -cp jodbc.jar ianywhere.ml.jdbcodbc.jdbc3.IBuildNum

And, to check jodbc4.jar, execute:

java -cp jodbc4.jar ianywhere.ml.jdbcodbc.jdbc4.IBuildNum

Once you find out which dll/shared object or jar file is out of sync, ensure that that particular file is not locked by an application or some other mechanism and then reapply the EBF.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member

Placeholder.

Answers (1)

Answers (1)

Former Member

I have found that once you find the offending jar files you can delete them and re-apply the ebf with repair selected, otherwise, short of removing and re-installing Sybase, it doesn't do anything. There doesn't appear to be a method of simply "Re-applying the ebf".

VolkerBarth
Contributor
0 Kudos

You may have a look at that FAQ which deals with a similar experience:

What might prevent a JAR file from getting EBF'ed?

Former Member
0 Kudos

If the file is locked by it being opened by a running process that can prevent the .jar from getting patched. This can happen with the admin tools that have fast launchers running, or just an open session of the utility. Deleting files can sometimes work (as noted by sziegler; sometimes required for the dbctrs DLL for example) but stopping the process should work.