Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6431955

jdk 1.5.0_06 64 bit JDBC-ODBC Bridge does not appear to be linked to the ODBC core libraries.

    XMLWordPrintable

    Details

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              asaha Abhijit Saha
              Reporter:
              duke J. Duke (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: