There are two basic problems being presented here.

1. The 64 bit JDBC-ODBC Bridge does not appear to be linked to the ODBC
core libraries.

2. The 64 bit JDBC-ODBC Bridge appears to be using SQLINTEGER rather
than SQLLEN for the last parameter of SQLColAttributes.

64-BIT:

nc-suppsun[/home/tonyh/15019845]% java64 -version

java version "1.5.0_06"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode)

32-BIT:

nc-suppsun[/home/tonyh/15019845]% java -version

java version "1.4.1_06"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01)

Java HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode)

 
I have attached a tar file containing the following files:

working_truss.log
failing_truss.log
BridgeTest.java

The 32-bit version appears to be working fine for 1.5.0_06. The problem is only with the 64-bit version.

The customer ran and created two truss logs. The "working_truss.log" is a truss of
running with the 32 bit compiled BridgeTest.class. You can search in
the file for "libodbc" and you can see that libodbcinst.so.1 and
libodbc.so are searched for and found and loaded.

In "failing_truss", which was created with the 64 bit compiled version
of BridgeTest.class, you can search for "libodbc" and it is not found at
all indicating that the odbc core libraries are not being linked to.

With logging on
(java.sql.DriverManager.setLogStream(java.lang.System.out);), the
following output is seen when running the 64 bit version:

nc-suppsun[/home/tonyh/15019845]% java64 BridgeTest
JdbcOdbcDriver class loaded
DriverManager.initialize: jdbc.drivers = null
JDBC DriverManager initialized
registerDriver:
driver[className=sun.jdbc.odbc.JdbcOdbcDriver,sun.jdbc.odbc.JdbcOdbcDriv
er@1ef6a746]
DriverManager.getConnection("jdbc:odbc:OracleWP;UID=scott;PWD=tiger")
    trying
driver[className=sun.jdbc.odbc.JdbcOdbcDriver,sun.jdbc.odbc.JdbcOdbcDriv
er@1ef6a746]
*Driver.connect (jdbc:odbc:OracleWP;UID=scott;PWD=tiger)
JDBC to ODBC Bridge: Checking security
No SecurityManager present, assuming trusted application/applet
JDBC to ODBC Bridge 2.0001
Current Date/Time: Fri May 26 16:39:58 EDT 2006
Loading JdbcOdbc library
Allocating Environment handle (SQLAllocEnv)
ld.so.1: /usr/jdk1.5.0_06/bin/sparcv9/java: fatal: relocation error:
file /usr/jdk1.5.0_06/jre/lib/sparcv9/libJdbcOdbc.so: symbol
SQLAllocEnv: referenced symbol not found
Killed


This further shows that the symbols for the ODBC software are not
available.

You can use an environment variable, LD_PRELOAD to load the libodbc.so,
libodbcinst.so, and libivicu21.so. This will get far enough to make a
connection, however, as soon as the bridge attempts to call
SQLColAttributes, the application crashes. Unfortunately, the odbctrace
log does not show enough information to know what type of datatype that
the bridge is using for the last parameter of this odbc function,
however, you should be able to look at the source of the bridge and see
if it is specifying a SQLINTEGER rather than SQLLEN as specified for 64
bit ODBC applications.

They were able to reproduce a similar crash using a 64 bit ODBC application
by specifying the wrong datatype for the last parameter of
SQLColAttributes. This supported the theory that the Bridge was doing
the same.
(1) which OS is the program run ?

ANSWER: Solaris.

(2) which hardware is the program run ?
(AFAIK this should run on Itanium machines or Opteron 64 bit machines we
recently had and there was a 64 bit OS from Windows for these hardware.

ANSWER: SunOS nc-suppsun 5.9 Generic_117171-15 sun4u sparc
SUNW,Sun-Fire-V210

(3) The program for 32 bit and 64 bit is being run on differrent machines/hardware.
Just to confirm, is that true ? What is the environment for 32 bit vs 64 bit ?

ANSWER: Both the 32 bit and 64 bit scenario were run on the same machine as
listed above in questions 1 and 2. I used 32 bit JDK for the 32bit
version of the application as well as 32 bit ODBC software and used 64
bit JDK for 64 bit version and used 64 bit ODBC software.

(4) Which jdk build are you looking the fix for ? jdk5.0u7 is already
out ?

ANSWER: I don't know which version of the JDK is desired. I imagine as long as
it fixes the problem, then Hyperion will want to use it. Hyperion would
be better to answer this question.

(5) What is the jdk used in both environments ? java -version ?

32 bit
---------
java version "1.4.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01)
Java HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode)

64 bit
----------
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode)



In regards to obtaining the ODBC Software, Sun already licenses copies
of our software. If those are not available to you, you can download an
evaluation copy from our website at:


http://www.datadirect.com/downloads/registration/connect64_odbcunix/index.ssp

Just fill out the form and you will be able to download a full install.

In response to how these ODBC drivers differ when compared to the
SQLServer 64 bit driver, I am not sure I know, but you can see in the
truss logs I have provided to Venu Konda that the odbc library is never
searched for or accessed, but in 32 bit, it is. Also, the datatype for
the last parameter for SQLColAttributes seems to be something other than
SQLLEN. I believe SQL_INTEGER is being used. You will be able to best
identify this in the bridge code.

Let me know if you have any further questions and I will be happy to
help in any way that I can.

Best regards,

Tony Hall
Support Engineer
Datadirect Technologies
www.datadirect.com