Technical FAQ: Questions about jdbcKona/MSSQLServer
FAQ Index
Differences in WebLogic's and
Microsoft's JDBC driver
What are the major differences between WebLogic's JDBC drivers for
Microsoft and the one provided by Microsoft for their SQL server?
Microsoft provides only an ODBC
driver with their SQL Server, and their JDBC
driver for MS SQL Server requires the use of the JDBC-ODBC bridge
. JavaSoft doesn't recommend the use of the bridge unless
there are no other JDBC drivers available for your database.
For Java applications, JDBC drivers -- drivers that do not need ODBC --
are easier to work with and provide better performance. WebLogic
markets two two-tier
JDBC drivers that do not use ODBC. jdbcKona/MSSQLServer is a Type 2
driver; it uses the DB-LIB client libraries that work with MS SQL
Server, rather than ODBC. jdbcKona/MSSQLServer4 is a pure-Java, Type 4
JDBC driver that will run on any platform. Neither of WebLogic's JDBC
drivers require the bridge to work with the database, which provides
better performance and makes your programs easier to write, debug, and
maintain. For more information on types of JDBC drivers, read the
whitepaper Choosing a JDBC
driver.
What's this "No Data Available" exception?
I'm getting an exception "No Data Available"
from my jdbcKona/MSSQLServer program. I know that there is data in the
database tables. Why am I getting this exception?
The SQLException "No Data Available" from
jdbcKona/MSSQLServer indicates that you have probably not called the
close() method on your JDBC
Statements. This exception is thrown if there is something wrong with
the underlying Statement, and the most likely cause is that the
Connection is being actively used by or in another query, which isn't
supported with MS SQL Server. Not properly closing your Statements can
lead to such a corruption of the Connection.
Does jdbcKona/MSSQLServer
support version 6.5 of MS SQL Server?
Does jdbcKona/MSSQLServer support version 6.5 of Microsoft SQL Server?
Yes, it does. In addition, we have had reports of problems with
jdbcKona/MSSQLServer that were cleared up with the installation of
SQL Server Service Pack 3 for Microsoft SQL Server v6.5,
available from the Microsoft's FTP site. You will
need the patch whose name is "65SP3" plus an abbreviation for your
architecture, either "X86" or "ALP". We highly recommend that you
install this patch.
I can't get my JetConnect/ODBC
code to work with jdbcKona/MSSQLServer version 2.4
I installed your evaluation package on my Windows NT 4.0 workstation
along with the client-side drivers and utilities for MS SQL Server. I
took a piece of working code that I had been using with JetConnect and
ODBC and swapped the configuration to use your product. It compiles
but will not run. The error message just says:
C:\WEBLOGIC\TEST>jvc myscript
Microsoft (R) Visual J++ Compiler Version 1.01.7017
Copyright (C) Microsoft Corp 1996. All rights reserved.
C:\WEBLOGIC\TEST>jview myscript
Loading the driver...
Connecting to the database...
ERROR: java.lang.UnsatisfiedLinkError
Any ideas what the problem might be?
Yes, and it doesn't have anything to do with your code, which should
work fine. The problem is that you cannot use the WebLogic two-tier
jdbcKona drivers prior to version 2.5 with J++, because Microsoft uses
a native method implementation that is different from JavaSoft's. In
version 2.5, we have added native libraries to our distribution that
work with Microsoft J++. The .dll for MSSQLServer is something similar
to weblogicmssql24.dll
(the number may be different in your distribution).
NoClassDefFoundError when downloading an applet
I have a client application that can be run either as a standalone
application or as an applet in a browser. When it is run as a
standalone application, it works fine, but when it is downloaded in a
browser, using the Java Plug-in, I get a NoClassDefFoundError. How can I make this application
run in a browser?
The problem is probably with the Java Plug-in; WebLogic is currently
working on this problem. As a workaround, you can point the Plug-in to
the 1.1.5 Java Runtime Environment or JDK
,
instead of 1.1.6.
How can I access a Microsoft SQL Server database from Solaris or Macintosh?
We need to access a MS SQL Server database (running on a Windows NT
machine) from a variety of machines with different operating systems
on our network, including Solaris workstations, PCs running OS/2, and
various Mackintoshes. Have you got a solution?
Yes! WebLogic JDBC
can be used to provide a database client-side application (no vendor
libraries required) for any operating system for which there is a Java
Virtual Machine.
So, although there are no vendor libraries for Microsoft SQL Server
access provided for Solaris, OS/2, or Macintosh, you can use our
WebLogic JDBC multitier
JDBC
implementation, included with the package WebLogic Express, from these
machines to talk to a SQL Server database running on NT. With WebLogic
Express, you can access your SQL Server database from Mackintoshes,
workstations running various flavors of UNIX, PCs running OS/2 -- even
a PC running Linux! -- with one WebLogic Express application.
We also have users who access a Microsoft SQL Server database from
Solaris with our two-tier jdbcKona/Sybase driver and the Solaris
Sybase .so, which is done by creating an entry for the MS SQL Server
database in your interface file on the Solaris machine. For a Solaris
client accessing SQL Server running on NT, you may choose to use
either jdbcKona/Sybase for a native, two-tier solution
,
or WebLogic JDBC for a Java-only solution.
Here are some brief instructions for the two-tier solution:
- You will need Sybase's OpenClient DB-LIB on the Solaris machine.
- You will need the MS SQL Server to listen on a TCP
port. By default, it listens on a named pipe, but you can configure it
to listen with TCP, too. The default port number is 1433 (which is
fine).
- You will need to list the MS SQL Server with the NT machine name and
the port number in the Sybase interfaces file. This file is called
"interfaces," and is located in the Sybase root directory.
- Then you will need to use the class name and URL for the WebLogic
jdbcKona/Sybase driver in your code.
SQLExceptions with jdbcKona/MSSQLServer
I'm using jdbcKona/MSSQLServer, and I'm getting SQLExceptions for some
pretty simple queries. My code used to work. What's the problem?
With version 2.5.x of WebLogic's software and later, You must be
running version 6.50.258 of MS SQL Server. The latest patches are
available from the Microsoft FTP site. You will
need the patch whose name is "65SP3" plus an abbreviation for your
architecture, either "X86" or "ALP". Installation of this patch
requires that you have already installed Windows NT Service Pack
3. Installing this patch will add the .dlls msdblib3.dll and w3dblib.dll to your \MSSQL\bin (with a standard installation).
Are there restrictions on selecting SQL Server Text and Image data?
In my application, I need to select columns of type Text/Image. What
kind of restrictions are there in jdbcKona/Sybase and
jdbcKona/MSSQLServer on these operations?
When selecting columns of type text or image with the methods
ResultSet.getString(), ResultSet.getBytes(), or ResultSet.getObject(),
there is a default limit of 32K that can be returned by a SQL select.
You can increase this limit with the Statement.setMaxFieldSize()
method, but if you set it to a very large limit, the JDBC
driver can potentially run out of memory.
Read more about handling columns of type text or image in the Developers guide for
jdbcKona/Sybase and jdbcKona/MSSQLServer.
Is there a length limit on retrieving Microsoft SQL Server text fields?
There seems to be a length limit when you
retrieve a Text field from Microsoft SQL Server. No matter why I do, I
can't retrieve a field of more than 4096 bytes. If I use getString()
and check the length of the string, it is always 4096; if I read with
getAsciiStream(), it always stops at 4096.
With Microsoft SQL Server, you have to specify an explicit maximum
size through SQL if a BLOB value might exceed 4096. The syntax for
this is:
SET TEXTSIZE number
where number is the maximum number of bytes to be retrieved.
