on 2011 May 12 9:55 AM
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.
Placeholder.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You may have a look at that FAQ which deals with a similar experience:
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.
User | Count |
---|---|
68 | |
10 | |
10 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.