Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with Weblogic and Microsofts JDBC driver and transactional datasources..

1 view
Skip to first unread message

Avinash Chugh

unread,
Feb 8, 2002, 6:14:03 AM2/8/02
to
I am working on an application in the following environment: Windows
2000 Server Sp2, Weblogic 6.1sp1, MS SQL Server 7sp3. Our application
workes fine with Weblogic's JDriver for MS SQL Server 7/2000 (JDBC1
driver).

When I switched to current release of Microsoft SQL Server 2000 Driver
for JDBC (Type 4 JDBC 2 driver), I got following exception when I
tried to login:

java.sql.SQLException: [Microsoft][SQLServer JDBC Driver]Can't start a
cloned co
nnection while in manual transaction mode.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown
Source
)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown
Source)
at com.microsoft.jdbc.base.BaseConnection.getImplConnection(Unknown
Sour
ce)
at com.microsoft.jdbc.base.BaseStatement.setupImplConnection(Unknown
Sou
rce)
at com.microsoft.jdbc.base.BaseStatement.<init>(Unknown
Source)
at com.microsoft.jdbc.base.BasePreparedStatement.<init>(Unknown
Source)
at com.microsoft.jdbc.base.BaseConnection.prepareStatement(Unknown
Sourc
e)
at com.microsoft.jdbc.base.BaseConnection.prepareStatement(Unknown
Sourc
e)
at weblogic.jdbc.common.internal.ConnectionEnv.getStatementHolderForCach
edPrepared(ConnectionEnv.java:240)
at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:117)
at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(Connection
Impl.java:135)
at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.
java:76)

So the connection-pool initialised without errors...the session bean
uses a transactional datasource where all methods are set to either
"Requires" or "Supports" transactions...

Have I discovered a bug in Microsoft's JDBC 2.0 driver?

Regards
Avinash Chugh

Joseph Weinstein

unread,
Feb 8, 2002, 2:42:18 PM2/8/02
to Avinash Chugh
You have to configure the pool with additional properties for the MS driver,
to set CURSORMODE=true. See their docs.
Joe

Avinash Chugh

unread,
Feb 8, 2002, 4:24:54 PM2/8/02
to
Cheers Joe! You're the man! That made the problem go away.

Now we get a problem when we attempt to set a parameter within
preparedstatement - which maps to SQL-Server type of uniqueidentifier.

Specific exception is:

[java.sql.SQLException: [Microsoft][SQLServer JDBC
Driver][SQLServer]Syntax erro
r converting from a character string to uniqueidentifier.]
java.sql.SQLException: [Microsoft][SQLServer JDBC
Driver][SQLServer]Syntax error
converting from a character string to uniqueidentifier.


at
com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source
)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown
Source)
at

com.microsoft.jdbc.sqlserver.tds.TDSRequest.processErrorToken(Unknown
Source)
at
com.microsoft.jdbc.sqlserver.tds.TDSRequest.processReplyToken(Unknown
Source)

According to their documentation, SQL-Server type "uniqueidentifier"
maps to JDBC type "varbinary".

When we were using Weblogic's SQL-Server driver, we could treat
uniqueidentifier columns as "strings". But with Microsoft's JDBC driver,
I can't treat uniqueidentfiers as "strings", while setting the
parameters of a preparedstatement. Although, I can still continue to
read uniqueidentifier columns returned in resultsets as strings.

It will be annoying to have to change our code to
ps.setBytes(n, id.getBytes()) instead of ps.setString(n, id)
which is what we have at the moment spread over all our source.

Another thing I notice is:

With Weblogic's driver, a getString() on unique-identifier gives me
(say) 73B96A56-0344-48EB-B9DC-8133BFDC519D
With Microsoft's driver, a getString() on unique-identifier gives me
73B96A56034448EBB9DC8133BFDC519D.

Regards
Avinash Chugh.

Joseph Weinstein

unread,
Feb 8, 2002, 5:13:11 PM2/8/02
to Avinash Chugh
Avinash Chugh wrote:

> Cheers Joe! You're the man! That made the problem go away.

Thanks! :-)

> Now we get a problem when we attempt to set a parameter within
> preparedstatement - which maps to SQL-Server type of uniqueidentifier.

Yep. The real problem starts with MS SQLServer. The unique identifier
column *is* a small varbinary type, but for whatever reason, MS has a
visual format for the data in this field that is different than the way the data
is actually generated and stored in the DBMS. The MS driver is treating
this column like any other varbinary column, and such a column won't
have a reliable way to convert it's contents to a Java string. Our driver
does detect this column type, and we have added the MS-specific
conversion to re-order the data once we get it into the driver, and
then to present it in the MS-style string. This could be added to the MS
driver if they choose to. Ie: the metadata coming back with this column
to the driver does contain enough info for any driver to know when a
varbinary is or is not a unique identifier, and can treat the identifiers
specially in getString(). Generically though, getBytes() and setBytes()
would work everywhere.
Joe

0 new messages