/usr/share/doc/libjtds-java/html/faq.html is in libjtds-java 1.2.5+dfsg-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 | <html>
<head>
<title>jTDS JDBC Driver</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Keywords" content="jTDS, open source, free JDBC driver, free driver, free, JDBC, JDBC 2.0, JDBC 3.0, driver, type 4, pure Java, SQL Server, Sybase, SQL Server 6.5, SQL Server 7.0, SQL Server 2000, SQL Server 2005, SourceForge">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body>
<table class="mainTable" cellpadding="0" cellspacing="0">
<tr>
<td colspan="3" class="logoWrapper">
<table cellpadding="0" cellspacing="0" class="logo">
<tr>
<td class="logo"><img src="images/logo.gif" alt="The jTDS Project" class="logo"></td>
<td class="logo"><img src="images/logoBg.gif" class="logoBg"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td colspan="3"> </td>
</tr>
<tr>
<td width="9" height="9"><img src="images/maintl.gif" width="9" height="9"></td>
<td height="9" background="images/maint.gif"><img src="images/spacer.gif"></td>
<td width="9" height="9"><img src="images/maintr.gif" width="9" height="9"></td>
</tr>
<tr>
<td width="9" background="images/mainl.gif"><img src="images/spacer.gif"></td>
<td class="content">
<p class="links">
<a href="index.html">Home</a>
| <span class="selected">FAQ</span>
| <a href="doc.html">Documentation</a>
| <a href="links.html">Links</a>
| <a href="license.html">License</a>
| <a href="http://sourceforge.net/projects/jtds">Project Info</a>
| <a href="http://sourceforge.net/project/showfiles.php?group_id=33291">Download</a>
| <a href="http://sourceforge.net/news/?group_id=33291">News</a>
| <a href="http://sourceforge.net/tracker/?group_id=33291&atid=407762">Bugs</a>
| <a href="http://sourceforge.net/forum/?group_id=33291">Forums</a>
</p>
<!--
==================================
Content starts here
==================================
-->
<p class="title">Frequently Asked Questions</p>
<p class="question">Getting Started</p>
<ul>
<li><a href="#driverImplementation">What are the class names of the <code>Driver</code>,
<code>DataSource</code>, <code>ConnectionPoolDataSource</code>, <code>XADataSource</code>
and <code>ObjectFactory</code> implementations?</a></li>
<li><a href="#urlFormat">What is the URL format used by jTDS?</a></li>
<li><a href="#benchmarks">jTDS is supposed to be the fastest JDBC driver
around. Have you got any figures to prove that? Or even better, a
benchmark I can run myself?</a></li>
<li><a href="#features">Which JDBC features are and which features are
not supported by jTDS?</a></li>
<li><a href="#multithreading">Can jTDS be used in a multi threaded
application?</a></li>
</ul>
<p class="question">Error Conditions</p>
<ul>
<li><a href="#classNotFound">Why do I get a <code>ClassNotFoundError</code>
when calling <code>Class.forName("net.sourceforge.jtds.jdbc.Driver")</code>?</a></li>
<li><a href="#noSuitableDriver">Why do I get a <code>java.sql.SQLException:
"No suitable driver"</code> when trying to get a connection?</a></li>
<li><a href="#connectionRefused">Why do I get <code>java.sql.SQLException:
"Network error IOException: Connection refused: connect"</code>
when trying to get a connection?</a></li>
<li><a href="#instanceName">Where does one place an instance name in the
connect string? Connecting with <code>"jdbc:jtds:sqlserver://host\instance:port/database"</code>
gives an SQLException with the message "Logon failed".</a></li>
<li><a href="#instanceGetInfo">Why do I get a <code>java.sql.SQLException:
"Unable to get information from SQL Server"</code> when
trying to connect to an SQL Server instance?</a></li>
<li><a href="#windowsAuth">I was hoping that appending <code>";domain=X"</code>
to the URL would be enough on a workstation that was already logged
into domain X. Why do I still need to provide a username and password?</a></li>
<li><a href="#expectingResultSet"><code>executeQuery()</code> throws
<code>java.sql.SQLException: "The executeQuery method must return a
result set."</code>.</a></li>
<li><a href="#forwardOnlyResultSet">I get <code>java.sql.SQLException:
"ResultSet may only be accessed in a forward direction"</code>
or <code>"ResultSet is read only"</code> when using a
scrollable and/or updateable <code>ResultSet</code>.</a></li>
<li><a href="#sqlStates">Not all <code>SQLException</code>s thrown by
jTDS seem to have associated meaningful SQL state values.</a></li>
<li><a href="#batchProcessing">Batch processing with executeBatch()
hangs or is unreliable on Sybase.</a></li>
</ul>
<p class="question">Incorrect Behavior</p>
<ul>
<li><a href="#callableStatementOutput"><code>CallableStatement</code>
output parameter getter throws <code>java.sql.SQLException:
"Parameter <i>X</i> has not been set."</code>.</a></li>
<li><a href="#lastUpdateCount">
<code>PreparedStatement.executeUpdate()</code> returns an incorrect
update count.</a></li>
<li><a href="#badrpccall">Why do I get <code>java.sql.SQLException:
"Output parameter not allowed
as argument list prevents use of RPC."</code>
when calling a stored procedure?</a></li>
</ul>
<p class="question">Memory Usage</p>
<ul>
<li><a href="#preparedStatmentMemoryLeak">Memory usage keeps increasing
when using generated <code>PreparedStatements</code>.</a></li>
</ul>
<p class="question">TDS Protocol Version</p>
<ul>
<li><a href="#getConnectionHangs">I'm trying to connect to SQL Server
6.5, but it hangs when calling <code>getConnection()</code>.</a></li>
<li><a href="#longColumnNames">Why do column names more than 30 characters
long, get chopped off at 30 characters?</a></li>
<li><a href="#imageData4k">jTDS fetches only the first 4Kb of <code>IMAGE</code>
data.</a></li>
<li><a href="#connectOmnibus">What do i have to do to connect to Netcool Omnibus
(or any derived Product).</a></li>
</ul>
<p class="question">Technical Support</p>
<ul>
<li><a href="#techSupport">Is there any commercial
technical support available for jTDS?</a></li>
</ul>
<p class="question">Other</p>
<ul>
<li><a href="#other">I didn't find the answer to my problem in this
FAQ. What should I do?</a></li>
</ul>
<p class="title">Getting Started</p>
<p class="question"><a name="driverImplementation"></a>What are the class names of the <code>Driver</code>,
<code>DataSource</code>, <code>ConnectionPoolDataSource</code>, <code>XADataSource</code> and
<code>ObjectFactory</code> implementations?</p>
<table class="inner" cellpadding="0" cellspacing="0">
<thead>
<tr><th>Interface</th><th>jTDS Implementation</th></tr>
</thead>
<tbody>
<tr><td><code>java.sql.Driver</code></td><td><code>net.sourceforge.jtds.jdbc.Driver</code></td></tr>
<tr><td><code>javax.sql.DataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
<tr><td><code>javax.sql.ConnectionPoolDataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
<tr><td><code>javax.sql.XADataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
<tr><td><code>javax.naming.spi.ObjectFactory</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsObjectFactory</code></td></tr>
</tbody>
</table>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="urlFormat"></a>What is the URL format used
by jTDS?</p>
<p>The URL format for jTDS is:</p>
<pre> jdbc:jtds:<server_type>://<server>[:<port>][/<database>][;<property>=<value>[;...]]</pre>
<p>where <code><server_type></code> is one of either <code>'sqlserver'</code>
or <code>'sybase'</code> (their meaning is quite obvious), <code><port></code>
is the port the database server is listening to (default is 1433 for SQL
Server and 7100 for Sybase) and <code><database></code> is the database
name -- JDBC term: catalog -- (if not specified, the user's default database
is used). The set of properties supported by jTDS is:</p>
<dl>
<dt><code>appName</code> (default - <code>"jTDS"</code>)</dt>
<dd>Application name. No practical use, it's displayed by Enterprise Manager
or Profiler associated with the connection.</dd>
<dt><code>batchSize</code> (default - <code>0</code> for SQL Server;
<code>1000</code> for Sybase)</dt>
<dd>Controls how many statements are sent to the server in a batch.
The actual batch is broken up into pieces this large that are sent
separately. The reason for this is to avoid Sybase "hangs" caused by
running out of space with very large batches. The problem doesn't
seem to occur with SQL Server, hence the default limit of 0
(unlimited) in this case.</dd>
<dt><code>bindAddress</code> (default - determined by the Java
implementation; requires Java 1.4 or later)</dt>
<dd>Specifies the local IP address to bind to for outgoing TCP/IP
connections to the database. Useful for multi-homed systems (those with
more than one external IP address) where the default IP address picked by
Java will not connect to the database. Currently has no effect when
using named pipes to connect to a database (see
<code>namedPipe</code>). Since after jTDS-1.2.</dd>
<dt><code>bufferDir</code> (default - <code>System.getProperty("java.io.tmpdir")</code>)</dt>
<dd>Controls the destination where data is buffered to disk.<br/>
See also <code>bufferMaxMemory</code> and <code>bufferMinPackets</code>.</dd>
<dt><code>bufferMaxMemory</code> (default - <code>1024</code>)</dt>
<dd>Controls the global buffer memory limit for all connections (in
kilobytes). When the amount of buffered server response packets
reaches this limit additional packets are buffered to disk; there is
however one exception: each <code>Statement</code> gets to buffer at
least <code><bufferMinPackets></code> to memory before this
limit is enforced. This means that this limit can and will usually be
exceeded.<br/>
Server responses are buffered to disk only when a request is made on
a <code>Statement</code> while another <code>Statement</code>
belonging to the same Connection still hasn't processed all its
results. These situations can be avoided in most cases by setting the
<code>useCursors</code> property, but this will also affect
performance.<br/>
See also <code>bufferMinPackets</code>.</dd>
<dt><code>bufferMinPackets</code> (default - <code>8</code>)</dt>
<dd>Controls the minimum number of packets per statement to buffer to
memory. Each <code>Statement</code> will buffer at least this many
packets before being forced to use a temporary file if the
<code><bufferMaxMemory></code> is reached, to ensure good
performance even when one <code>Statement</code> caches a very large
amount of data.<br/>
Server responses are buffered to disk only when a request is made on
a <code>Statement</code> while another <code>Statement</code>
belonging to the same Connection still hasn't processed all its
results. These situations can be avoided in most cases by setting the
<code>useCursors</code> property, but this will also affect
performance.<br/>
See also <code>bufferMaxMemory</code>.</dd>
<dt><code>cacheMetaData</code> (default - <code>false</code>)</dt>
<dd>When used with prepareSQL=3, setting this property to
<code>true</code> will cause the driver to cache column meta data for
SELECT statements. Caching the meta data will reduce the processing
overhead when reusing statements that return small result sets that
have many columns but may lead to unexpected errors if the database
schema changes after the statement has been prepared. Use with care.
Only applicable to SQL Server (there is no prepareSQL=3 mode for
Sybase).
<dt><code>charset</code> (default - the character set the server was installed
with)</dt>
<dd>Very important setting, determines the byte value to character mapping
for <code>CHAR</code>/<code>VARCHAR</code>/<code>TEXT</code> values.
Applies for characters from the extended set (codes 128-255). For
<code>NCHAR</code>/<code>NVARCHAR</code>/<code>NTEXT</code> values
doesn't have any effect since these are stored using Unicode.</dd>
<dt><code>domain</code></dt>
<dd>Specifies the Windows domain to authenticate in. If present and the
user name and password are provided, jTDS uses Windows (NTLM)
authentication instead of the usual SQL Server authentication (i.e.
the user and password provided are the domain user and password).
This allows non-Windows clients to log in to servers which are only
configured to accept Windoes authentication.<br/>
If the <code>domain</code> parameter is present but no user name and
password are provided, jTDS uses its native Single-Sign-On library
and logs in with the logged Windows user's credentials (for this to
work one would obviously need to be on Windows, logged into a domain,
and also have the SSO library installed -- consult README.SSO in the
distribution on how to do this).</dd>
<dt><code>instance</code></dt>
<dd>Named instance to connect to. SQL Server can run multiple so-called
"named instances" (i.e. different server instances, running on different
TCP ports) on the same machine. When using Microsoft tools, selecting
one of these instances is made by using "<host_name>\<instance_name>"
instead of the usual "<host_name>". With jTDS you will have to
split the two and use the instance name as a property.</dd>
<dt><code>lastUpdateCount</code> (default - <code>true</code>)</dt>
<dd>If <code>true</code> only the last update count will be returned by
<code>executeUpdate()</code>. This is useful in case you are updating
or inserting into tables that have triggers (such as replicated tables);
there's no way to make the difference between an update count returned
by a trigger and the actual update count but the actual update count
is always the last as the triggers execute first. If <code>false</code>
all update counts are returned; use <code>getMoreResults()</code> to
loop through them.</dd>
<dt><code>lobBuffer</code> (default - <code>32768</code>)</dt>
<dd>The amount of LOB data to buffer in memory before caching to disk. The
value is in bytes for <code>Blob</code> data and chars for <code>Clob</code>
data.</dd>
<dt><code>loginTimeout</code> (default - <code>0</code> for TCP/IP connections
or <code>20</code> for named pipe connections)</dt>
<dd>The amount of time to wait (in seconds) for a successful connection
before timing out.<br/>
If a TCP/IP connection is used to connect to the database and Java 1.4 or
newer is being used, the <code>loginTimeout</code> parameter is used to set
the initial connection timeout when initially opening a new socket. A value
of zero (the default) causes the connection to wait indefinitely, e.g.,until
a connection is established or an error occurs. See also
<code>socketTimeout</code>.<br/>
If a named pipe connection is used (<code>namedPipe</code> is
<code>true</code>) and <code>loginTimeout</code> is greater than zero, the
value of <code>loginTimeout</code> is used for the length of the retry period
when "All pipe instances are busy" error messages are received while
attempting to connect to the server. If <code>loginTimeout</code> is zero
(the default), a value of 20 seconds is used for the named pipe retry
period.</dd>
<dt><code>macAddress</code> (default - <code>"000000000000"</code>)</dt>
<dd>Network interface card MAC address. It's displayed by Enterprise
Manager or Profiler associated with the connection and is needed to
resolve some issues regarding the number of clients allowed by the
SQL Server license. The MAC address cannot be determined automatically
from Java (i.e. without using native code) so you'll have to specify
it yourself if you need it.</dd>
<dt><code>maxStatements</code> (default - <code>500</code>)</dt>
<dd>The number of statement prepares each connection should cache.
A value of <code>0</code> will disable statement caching.
A value of <code>Integer.MAX_VALUE</code> (<code>2147483647</code>)
will enable fast caching (uses less memory and has no overhead
associated with removing statements); the cache will never release
any cached statements, so although experience has shown that this is
usually not a problem with most applications, use with care.</dd>
<dt><code>namedPipe</code> (default - <code>false</code>)</dt>
<dd>When set to <code>true</code>, named pipe communication is used to
connect to the database instead of TCP/IP sockets. When the
<code>os.name</code> system property starts with "windows"
(case-insensitive), named pipes (both local and remote) are accessed
through the Windows filesystem by opening a <code>RandomAccessFile</code>
to the path. When the SQL Server and the client are on the same machine,
a named pipe will usually have better performance than TCP/IP sockets
since the network layer is eliminated. Otherwise the
<a href="http://jcifs.samba.org/">JCIFS</a> library is used. JCIFS
provides a pure Java named pipe implementation and uses NTLM
authentication, so the <code>domain</code> parameter is required.<br/>
This feature supports the <code>instance</code> parameter (which changes
the named pipe URL), but it does not currently support the named pipe at
a location other than <code>/sql/query</code> on the server. The
<code>port</code> parameter is ignored if set.</dd>
<dt><code>packetSize</code> (default - <code>4096</code> for TDS 7.0/8.0;
<code>512</code> for TDS 4.2/5.0)</dt>
<dd>The network packet size (a multiple of 512).</dd>
<dt><code>password</code> (required)</dt>
<dd>Password to use for login. When using <code>getConnection(String url,
String user, String password)</code> it's not required to set this property
as it is passed as parameter, but you will have to set it when using
<code>getConnection(String url, Properties info)</code> or <code>JtdsDataSource</code>.</dd>
<dt><code>prepareSQL</code> (default - <code>3</code> for SQL Server,
<code>1</code> for Sybase)</dt>
<dd>This parameter specifies the mechanism used for Prepared Statements.
<table class="inner" cellpadding="0" cellspacing="0">
<thead>
<tr><th>Value</th><th>Description</th></tr>
</thead>
<tbody>
<tr><td><code>0</code></td><td>SQL is sent to the server each time without any preparation, literals are inserted in the SQL (slower)</td></tr>
<tr><td><code>1</code></td><td>Temporary stored procedures are created for each unique SQL statement and parameter combination (faster)</td></tr>
<tr><td><code>2</code></td><td>sp_executesql is used (fast)</td></tr>
<tr><td><code>3</code></td><td>sp_prepare and sp_cursorprepare are used in conjunction with sp_execute and sp_cursorexecute (faster, SQL Server only)</td></tr>
</tbody>
</table>
</dd>
<dt><code>progName</code> (default - <code>"jTDS"</code>)</dt>
<dd>Client library name. No practical use, it's displayed by Enterprise
Manager or Profiler associated with the connection.</dd>
<dt><code>processId</code> (default - <code>123</code>)</dt>
<dd>The client process ID associated with the connection. Must be an integer
value or the string "compute" to let jTDS choose a process ID.</dd>
<dt><code>sendStringParametersAsUnicode</code> (default - <code>true</code>)</dt>
<dd>Determines whether string parameters are sent to the SQL Server database
in Unicode or in the default character encoding of the database. This
seriously affects SQL Server 2000 performance since it does not automatically
cast the types (as 7.0 does), meaning that if a index column is Unicode
and the string is submitted using the default character encoding (or
the other way around) SQLServer will perform an index scan instead of
an index seek. For Sybase, determines if strings that cannot be encoded in
the server's charset are sent as unicode strings. There is a performance
hit for the encoding logic so set this option to false if unitext or univarchar
data types are not in use or if charset is utf-8.</dd>
<dt><code>socketTimeout</code> (default - <code>0</code>)</dt>
<dd>The amount of time to wait (in seconds) for a server response before timing out.<br/>
Use with care! If a non zero value is supplied this must be greater than the maximum
time that the server will take to answer any query. Once the timeout value is exceeded
the network or named pipe connection will be closed. This parameter may be useful for
detecting dead network connections in a pooled environment. See also
<code>loginTimeout</code>. If using named pipes via JCIFS the timeout cannot be
disabled completely. A timeout of about 25 days (2^31 ms) is applied instead.</dd>
<dt><code>socketKeepAlive</code> (default - <code>false</code>)</dt>
<dd>true to enable TCP/IP keep-alive messages</dd>
<dt><code>ssl</code> (default - <code>off</code>)</dt>
<dd>Specifies if and how to use SSL for secure communication.
<table class="inner" cellpadding="0" cellspacing="0">
<thead>
<tr><th>Value</th><th>Description</th></tr>
</thead>
<tbody>
<tr><td><code>off</code></td><td>SSL is not request or used; this is the default</td></tr>
<tr><td><code>request</code></td><td>SSL is requested; if the server does not support it then a plain connection is used</td></tr>
<tr><td><code>require</code></td><td>SSL is requested; if the server does not support it then an exception is thrown</td></tr>
<tr><td><code>authenticate</code></td><td>Same as <code>require</code> except the server's certificate must be signed by a trusted CA</td></tr>
</tbody>
</table>
</dd>
<dt><code>tcpNoDelay</code> (default - <code>true</code>)</dt>
<dd><code>true</code> to enable TCP_NODELAY on the socket;
<code>false</code> to disable it.</dd>
<dt><code>TDS</code> (default - <code>"8.0"</code> for SQL Server;
<code>"5.0"</code> for Sybase)</dt>
<dd>The version of TDS to be used. TDS (Tabular Data Stream) is the protocol
used by Microsoft SQL Server and Sybase to communicate with database
clients. jTDS can use TDS 4.2, 5.0, 7.0 and 8.0. Version 4.2 is used by
SQL Server 6.5 and Sybase 10. Version 5.0 is used with Sybase 11 onwards.
Version 7.0 is used by SQL Server 7.0; this protocol also works with SQL
Server 2000. Version 8.0 is used by SQL Server 2000 and SQL Server 2005.<br>
Newer database server versions usually understand older protocol versions.
This means that SQL Server 7.0 can be used with TDS 4.2, but the limitations
of the protocol apply regardless of the server version (e.g. when using TDS
4.2 <code>VARCHAR</code>s are limited to 255 characters). As a conclusion,
you must set this property to <code>"4.2"</code> when connecting
to SQL Server 6.5 or Sybase. You should not set this value to
<code>"7.0" or "8.0"</code>) when connecting to any
version of Sybase as these are SQL Server specific protocols. Further, you
should not set this value to <code>"5.0"</code>) when connecting
to any version of SQL Server as this is a Sybase specific protocol.<br/>
Currently jTDS automatically falls back from 8.0 to 7.0 (if used with
SQL Server 7.0) and from 5.0 to 4.2 (with Sybase 10) so specifying
the value for this parameter is only necessary for SQL Server 6.5.</dd>
<dt><code>useCursors</code> (default - <code>false</code>)</dt>
<dd>Instructs jTDS to use server side cursors instead of direct selects
(AKA firehose cursors) for forward-only read-only result sets (with
other types of result sets server- or client-side cursors are always
used).<br/>
With firehose cursors the SELECT query is sent and the server
responds with all the resulting rows. This is the fastest approach
but it means that the driver has to cache all results if another
request needs to be made before all rows have been processed. So when
using multiple <code>Statement</code>s per <code>Connection</code> it
is preferable to have server-side cursors instead; these will allow
the driver to request only a limited number of rows at a time
(controllable through the <code>fetchSize</code> property of a
<code>Statement</code>). This means extra request-response cycles,
but less caching by the driver.<br/>
With SQL Server a so called
<a href="http://msdn.microsoft.com/library/en-us/acdata/ac_8_con_07_3tdf.asp">fast
forward-only cursor</a> will be created when this property is set to
<code>true</code>. With Sybase a usual forward-only read-only cursor
is created.</dd>
<dt><code>useJCIFS</code> (default - <code>false</code>)</dt>
<dd>Controls whether the <a href="http://jcifs.samba.org/">jCIFS</a>
library will be used instead of the local file system with named pipe
connections on the Windows operating system. (The jCIFS library will
always be used with named pipes when the operating system is not
Windows.) Useful when connecting via named pipes to a server that is
located in a different domain than the client. See also
<code>namedPipe</code>. Since after jTDS-1.2.</dd>
<dt><code>useLOBs</code> (default - <code>true</code>)</dt>
<dd>Controls whether large types (IMAGE and TEXT/NTEXT) should be
mapped by default (when using <code>getObject()</code>) to LOBs or
Java types (<code>String</code> and <code>byte[]</code>). The default
JDBC type constant returned is also controlled by this property:
<code>Types.BLOB</code> for IMAGE and <code>Types.CLOB</code> for
TEXT/NTEXT when <code>true</code>, <code>Types.LONGVARBINARY</code>
for IMAGE and <code>Types.LONGVARCHAR</code> for TEXT/NTEXT when
<code>false</code>.<br/>
This is useful when printing out directly the values returned by
<code>getObject()</code> (e.g. when using JSTL or other frameworks),
as <code>Blob</code> and <code>Clob</code> don't implement
<code>toString()</code> (both because it's not required and because
it can easily lead to <code>OutOfMemoryError</code>s in unexpected
situations, such as when logging data). The default setting of
<code>true</code> has the advantage that the amount of data that is
cached in memory for a large object can be controlled via the
<code>lobBuffer</code> property; a setting of <code>false</code> will
still use the <code>Blob</code> and <code>Clob</code> implementations
internally but the values will be materialized to memory when
<code>getObject()</code> is called, possibly leading to memory
issues.</dd>
<dt><code>useNTLMv2</code> (default - false)</dt>
<dd>Set to <code>true</code> to send LMv2/NTLMv2 responses when using
Windows authentication</dd>
<dt><code>user</code> (required)</dt>
<dd>User name to use for login. When using <code>getConnection(String
url, String user, String password)</code> it's not required to set this
property as it is passed as parameter, but you will have to set it when
using <code>getConnection(String url, Properties info)</code> or
<code>JtdsDataSource</code>.</dd>
<dt><code>wsid</code> (default - the client host name)</dt>
<dd>Workstation ID. No practical use, it's displayed by Enterprise
Manager or Profiler associated with the connection.</dd>
<dt><code>xaEmulation</code> (default - <code>true</code>)</dt>
<dd>When set to <code>true</code>, emulate XA distributed transaction
support, when set to <code>false</code> use experimental true
distributed transaction support. True distributed transaction support
is only available for SQL Server 2000 and requires the installation
of an external stored procedure in the target server (see the
README.XA file in the distribution for details).</dd>
</dl>
<p>Properties can be passed to jTDS in one of three ways: in the URL, in
the <code>Properties</code> object passed to <code>getConnection()</code>
or by using the <code>JtdsDataSource</code>'s setters (if connections are
obtained through a <code>DataSource</code> rather than using the
<code>DriverManager</code>). Because there is no URL when using the
<code>JtdsDataSource</code> there are three other properties (with
setters and getters) to take the place of those items that are part of
the URL's syntax: <code>serverName</code>, <code>portNumber</code> and
<code>databaseName</code> (their meaning should be quite clear).</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="benchmarks"></a>jTDS is supposed to be the
fastest JDBC driver around. Have you got any figures to prove that? Or
even better, a benchmark I can run myself?</p>
<p>Actually we do have benchmark results from two different benchmarks,
both developed by large commercial SQL Server JDBC driver vendors to
demonstrate the performance of their own drivers. In our oppinion this
is better than having a benchmark of our own, which could be designed
in such a way as to give jTDS the edge. These benchmarks are free to
download so we encourage you to do it and run them yourself.</p>
<p>We have benchmarked jTDS against the two most used commercial drivers
and of course the Microsoft driver and the JDBC-ODBC bridge, using these
benchmarks:
<a href="http://www.inetsoftware.de/English/Produkte/OPTA/Benchmark.htm">i-net
software's BenchTest 2.1 for MS SQL Server</a> and
<a href="http://www.jnetdirect.com/downloads.php?op=performsuite">JNetDirect's
JDBC Performance Benchmark</a>. Here are the results of the i-net test:
<a href="benchTest.html">BenchTest 2.1 for MS SQL Server</a>. The JNetDirect
license precludes publication of performance test results. However, you
can run any of the benchmarks yourself, the effort is minimal.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="features"></a>Which JDBC features are and
which features are not supported by jTDS?</p>
<p>jTDS offers full support for all JDBC 3.0 features:
<a href="resultSets.html">forward-only and scrollable/updateable result
sets</a>, batch updates, prepared and callable
statements, unlimited number of statements per connection, complete
database and result set meta data, and a <code>DataSource</code>
implementation (which also implements <code>ConnectionPoolDataSource</code>
and <code>XADataSource</code>). Features such as generated keys
retrieval, named stored procedure parameters, and save points are also
implemented.</p>
<p>The only major features missing from jTDS are connection pooling and
row sets; the reason for leaving these out is that there are free
implementations available, probably much better than anything we could
come up with. Check out the jTDS <a href="features.html">feature
matrix</a> for more details.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="multithreading"></a>Can jTDS be used in a
multi threaded application?</p>
<p>As a general principle we try and keep synchronization to a minimum
both for performance and deadlock reasons. The only part of jTDS we
guarantee is thread safe is the <code>Connection</code> object, and
multi threaded access to <code>Statement</code>s is discouraged (except
for issuing cancels).</p>
<p>As a conclusion the only safe multithreading scenarios are these: (i)
one <code>Connection</code> with multiple <code>Statement</code>s, each
<code>Statement</code> used by a single thread and (ii) a
<code>Statement</code> used by one thread and cancelled by some other
thread. Scenario (i), while it does work, is not necessarily a good
solution because it requires a lot of locking and waiting on the same
network connection plus (last but not least) a lot of caching.
<p><a href="#">^ top ^</a></p>
<p class="title">Error Conditions</p>
<p class="question"><a name="classNotFound"></a>Why do I get a
<code>ClassNotFoundError</code> when calling
<code>Class.forName("net.sourceforge.jtds.jdbc.Driver")</code>?</p>
<p><code>ClassNotFoundError</code> is thrown by the classloader when it
can not find a certain class. In this case it's the
<code>net.sourceforge.jtds.jdbc.Driver</code> class, which means that
<code>jtds.jar</code> is not in the classpath. If you are getting this
in an application, start your application with</p>
<pre> java -cp <path_to_jtds>/jtds.jar <main_class></pre>
<p>If you experience this problem in a servlet/JSP you will have to add
<code>jtds.jar</code> to your web application's class path (e.g. by
editing the application's web.xml file or by copying the jar into the
application's/server's <code>/lib</code> directory).</p>
<p><b>Note:</b> The name of the jTDS jar file may be <code>jtds-1.2.jar</code>
or something similar. If that's the case, replace <code>jtds.jar</code>
in the above example with <code>jtds-1.2.jar</code> or whatever your specific
file name is.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="noSuitableDriver"></a>Why do I get a <code>java.sql.SQLException:
"No suitable driver"</code> when trying to get a connection?</p>
<p>The <code>"No suitable driver"</code> exception is thrown by
the <code>DriverManager</code> when none of the registered <code>Driver</code>
implementations recognizes the supplied URL. This means that you either
did not register jTDS with the <code>DriverManager</code> first (by calling
<code>Class.forName("net.sourceforge.jtds.jdbc.Driver")</code>)
or you mistyped the URL (e.g. <code>"jbdc:jtds:..."</code>
instead of <code>"jdbc:jtds:..."</code>).</p>
<p>A common mistake is to append a semicolon (";") to the end of the URL
(e.g. <code>"jdbc:jtds:sqlserver://server/db;TDS=7.0;"</code> is wrong!).
<p>For more information about URL format and the properties that may be
passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="connectionRefused"></a>Why do I get
<code>java.sql.SQLException: "Network error IOException: Connection
refused: connect"</code> when trying to get a connection?</p>
<p>The <code>"Connection refused"</code> exception is thrown by
jTDS when it is unable to connect to the server. There may be a number
of reasons why this could happen:</p>
<ol>
<li>The server name is misspelled or the port number is incorrect.</li>
<li>SQL Server is not configured to use TCP/IP. Either enable TCP/IP
from SQL Server's Network Utility app or have jTDS connect via named
pipes (see the <a href="#urlFormat">URL format</a> for information on
how to do this).</li>
<li>There is a firewall blocking port 1433 on the server.</li>
</ol>
<p>To check whether TCP/IP is enabled and the port is not blocked you can
use "telnet <server_host> 1433". Until telnet doesn't connect,
jTDS won't either. If you can't figure out why, ask your network
administrator for help.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="instanceName"></a>Where does one place an instance
name in the connect string? Connecting with
<code>"jdbc:jtds:sqlserver://host\instance:port/database"</code> gives an
SQLException with the message "Logon failed".
<p>You will have to use the <code>instance</code> property (either append it to the
URL or place it into the <code>Properties</code> you supply to <code>getConnection</code>)
instead of doing it the Microsoft way. Sorry, but jTDS (and its ancestor
FreeTDS) existed a long time before named instances so the URL could not
be changed (and using it this way confuses the URL parser).
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="instanceGetInfo"></a>Why do I get a
<code>java.sql.SQLException: "Unable to get information from SQL
Server"</code> when trying to connect to an SQL Server instance?</p>
<p>The exception you are getting is usually caused by a timeout. When
connecting to named instances jTDS needs to connect via UDP to port 1434
to get information about available SQL Server instances. While doing
this it times out, throwing the exception you see (which means that jTDS
was not able to get information about the running instances).</p>
<p>Connection timeouts occur when there is no server listening on the port
(BTW, are you sure your SQL Server is configured to use TCP/IP and that
you actually use named instances?).</p>
<p>On SQL Server 2005 the SQL Browser service must be running on the
server host as the instance name lookup port UDP 1434 is hosted by this
service on SQL Server 2005 rather than the SQL Server itself. The
default install does not configure the SQL Browser service to start
automatically so you must do it manually.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="windowsAuth"></a>I was hoping that appending
<code>";domain=X"</code> to the URL would be enough on a workstation that
was already logged into domain X. Why do I still need to provide a username
and password?</p>
<p>jTDS is a type 4 (pure Java) JDBC driver. This means (among other things)
that it cannot access platform-specific features, such as determining the
currently logged user and his credentials. jTDS is distributed with a
native library (DLL) for Single-Sign-On support, but that only works on
Windows (please consult README.SSO in the distribution package for
information on how to install it).</p>
<p>Without the native SSO library installed you still have to provide the
username and password because otherwise jTDS cannot determine user
credentials. There is a good side to this: users on non-Windows
platforms are able to log in using Windows credentials by providing
them in the URL, along with the domain name.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="expectingResultSet"></a>
<code>executeQuery()</code> throws <code>java.sql.SQLException: "The
executeQuery method must return a result set."</code>.</p>
<p>The <a href="http://java.sun.com/products/jdbc/download.html">JDBC
spec</a> and
<a href="http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#executeQuery(java.lang.String)">API
documentation</a> for <code>Statement</code> both state that
<code>executeQuery()</code> is intended to be used with queries that
return a <code>ResultSet</code>, typically <code>SELECT</code>
statements. On the the other hand, <code>executeUpdate()</code> is
intended for <code>INSERT</code>, <code>UPDATE</code>,
<code>DELETE</code> or DDL statements that return update counts. Both of
these (<code>ResultSets</code> and update counts) are considered by JDBC
to be "results". For queries that return multiple results the JDBC spec
requires <code>execute()</code> to be used.</p>
<p>If you'll look at the query you are trying to execute, you'll see that
it probably returns an update count first, followed by a
<code>ResultSet</code>. So according to the JDBC spec you should use
<code>execute()</code> to run it, call <code>getMoreResults()</code> to
skip the update count and then call <code>getResultSet()</code> to
obtain the <code>ResultSet</code> you want.</p>
<p>As a sidenote, The Microsoft driver (and probably the others, too)
"optimize" this behavior by skipping over the update count, which is
wrong according to the JDBC spec. So, for maximum compatibility, it is
recommended that you use <code>execute()</code> anytime you run queries
returning more than one result even if the particular driver you are
using allows you to do otherwise.</p>
<p>The same thing happens with the ODBC SQL driver and other connectors.
A common solution rather than the inelegant execute() and then cycling
through multiple result sets, is to supress the update counts for
statements you are uninterested in. This is common if say you are
querying a stored procedure that creates a temp table, runs updates
against it and then returns the table as a result set. You can
suppress all the extra "query results" by specifying "<code>SET NOCOUNT
ON</code>".</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="forwardOnlyResultSet"></a>I get
<code>java.sql.SQLException: "ResultSet may only be accessed in a
forward direction"</code> or <code>"ResultSet is read
only"</code> when using a scrollable/updateable
<code>ResultSet</code>.</p>
<p>There are three possible causes to this (if we exclude not creating
the <code>ResultSet</code> with the appropriate type and concurrency in
the first place):</p>
<ol>
<li>The executed query must be a single SELECT statement or a call to a
procedure that consists of a single SELECT statement (even a SET or
PRINT will cause the resulting ResultSet to be forward only read
only). This is a SQL Server limitation and there's not much jTDS can
do about it.</li>
<li>The scroll insensitive/updateable combination is not supported by
SQL Server, so such a <code>ResultSet</code> is automatically
downgraded to scroll insensitive/read-only by the server. Use the
scroll sensitive/updateable combination and it should work.</li>
<li>The other possible cause is that the cursor is keyset-based and
either the table you are selecting from does not have a unique primary
key or that primary key is not included in your <code>SELECT</code>.
See the
<a href="http://msdn.microsoft.com/library/en-us/acdata/ac_8_con_07_66sz.asp">SQL
Server Documentation on cursor types</a> for more information.</li>
</ol>
<p>In both cases if you call <code>Statement.getWarnings()</code> right
after calling <code>executeQuery()</code> you'll get a warning about the
<code>ResultSet</code> being downgraded. Also, please take a look at
our <a href="resultSets.html"><code>ResultSet</code> support page</a>
for some additional information and tips.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="sqlStates"></a>Not all
<code>SQLException</code>s thrown by jTDS seem to have associated
meaningful SQL state values.</p>
<p>Indeed, some SQLExceptions are reported with a correct state code
and some not. As the server itself does not return an SQL state code,
the SQLMessage class associates native error numbers with SQL state
codes (actually there's a very comprehensive map there); SQL Server
originated errors and warnings that are not found in this map are given
a default code of 'S1000', respectively '01000'. This is what happens
with SQL Server-returned errors and warnings and is consistent with how
other drivers handle exceptions. We have done our best to map as many
errors and warnings, however if you find some case in which other JDBC
or ODBC drivers return specific SQL states and jTDS doesn't or jTDS
returned SQL states that are obviously wrong, please let us know. We
will make the necessary changes.</p>
<p>See the
<a href="http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt">SQL
92</a> spec for the complete list and description of SQL state
codes.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="batchProcessing"></a>Batch processing
using executeBatch() hangs or is unreliable on Sybase.</p>
<p>When executing large batches on Sybase the client application may
hang or the response time may vary considerably. The client may be
suspended if the system log fills so check that the log space is
sufficient for the batch you are trying to load. You can control the
real batch size using the <code>batchSize</code> parameter; setting it
to a non-zero value will break up batches into smaller pieces on
execution, hopefully avoiding the problem.
<p>It is also recommended that you execute each batch in a transaction
(i.e. with auto commit set to false).
<p><a href="#">^ top ^</a></p>
<p class="title">Incorrect Behavior</p>
<p class="question"><a name="callableStatementOutput"></a>
<code>CallableStatement</code> output parameter getter throws
<code>java.sql.SQLException: "Parameter <i>X</i> has not been
set."</code>.</p>
<p>When executing a stored procedure (or any query, for that matter) the
response from the SQL Server is serialized in the same order it is
executed in: for stored procedures this means <code>ResultSet</code>s
and update counts first, output parameters and return value last. jTDS
only caches update counts , not <code>ResultSet</code>s because they
could easily cause <code>OutOfMemoryError</code>s or add important
performance overheads if cached to disk (the response would have to be
parsed twice, for example).
<p>As a conclusion, when executing stored procedures that only return
update counts output parameters will be available immediately, as jTDS
will process and cache the whole response. But if the stored procedure
returns at least one <code>ResultSet</code> jTDS will only cache the
update counts up to the first <code>ResultSet</code> and you will have
to call <code>getMoreResults()</code> to process all the results. So
for procedures returning <code>ResultSet</code>s you will have to loop,
consuming all results before reading the output parameters (i.e. until
<code>getMoreResults()</code> returns false AND
<code>getUpdateCount()</code> returns -1).</p>
<p>In case you are wondering if this is right, this is a quote from the
<code>CallableStatement</code> API documentation: "For maximum
portability, a call's <code>ResultSet</code> objects and update counts
should be processed prior to getting the values of output
parameters". Although this means that a "good" driver could "fix" this
behavior, fixing it would imply caching the whole server response,
equaling a huge performance drop.</p>
<p>The exception is thrown because it's better to warn the user that the
output parameters are not yet set instead of leaving the impression
that all is ok and cause other, harder to detect problems.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="lastUpdateCount"></a>
<code>PreparedStatement.executeUpdate()</code> returns an incorrect
update count.</p>
<p>This is caused by triggers; replication is also implemented through
triggers, so you will encounter this issue on replicated databases too.
The root cause is that triggers also return update counts and jTDS can't
make the difference between these update counts and the "real"
one (neither could any other SQL Server client). However, the update
count you need is the last of them (because the actual
<code>UPDATE</code>/<code>INSERT</code>/<code>DELETE</code> gets
executed only after the triggers) and there is luckily a parameter you
can specify in the URL (or the connection <code>Properties</code> or in
the <code>DataSource</code>) in order for jTDS to return only this last
update count (and ignore the rest of them). This parameter is
<code>lastUpdateCount</code> and you can find out more about it
<a href="#urlFormat">here</a>.</p>
<p>Please note that setting <code>lastUpdateCount</code> to
<code>true</code> could cause problems if you use queries that do
actually return more than one update count (such as queries consisting
of multiple updates/inserts), because it will also return only the last
of these update counts. Although queries returning multiple results are
not very common, it is the reason why this behavior is customizable from
the URL. Please note that this flag only alters the behavior of
<code>executeUpdate()</code>; <code>execute()</code> will still return
all update counts.</p>
<p>If you have both queries consisting of multiple
<code>UPDATE</code>s/<code>INSERT</code>s/<code>DELETE</code>s and
triggers you won't be able to set <code>lastUpdateCount</code> to
<code>true</code> if you want all the update counts, so you will have to
skip over the irrelevant update counts by calling
<code>getMoreResults()</code> yourself, when needed.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="badrpccall"></a>
Why do I get <code>java.sql.SQLException: "Output parameter not allowed
as argument list prevents use of RPC."</code> when calling a stored procedure?</p>
<p>When calling a stored procedure that has output parameters, the driver
has to call the procedure using a remote procedure call (RPC). Stored
procedures should be invoked using the special JDBC call escape syntax.
For example, {call sp_example(?,?)}. In this case the driver will be able
to use an RPC succesfully as all the parameters are represented by
parameter markers (?). If however parameters are supplied as a
mixture of parameter markers and literals, for example {call
sp_example('test',?)}, then the driver is unable to use an RPC
and therefore cannot return output parameters. In these circumstances the
driver raises an exception and execution fails.</p>
<p>It is possible to use mixed parameter lists to call stored procedures
that do not have output parameters. In this case the driver will substitute
the parameters locally and use a normal "execute procedure" SQL
call; however, this mode of execution is less efficient than an RPC.
</p>
<p><a href="#">^ top ^</a></p>
<p class="title">Memory Usage</p>
<p class="question"><a name="preparedStatmentMemoryLeak"></a>Memory usage
keeps increasing when using generated <code>PreparedStatements</code>.
</p>
<p>Normally, with a JDBC driver, <code>PreparedStatement</code>s are
precompiled on creation, which gives increased performance if they are
used a sufficient number of times. jTDS takes this one step further:
when you create a PreparedStatement, jTDS caches it internally and keeps
it there even after you close it so that every time you create it again
it doesn't need to be recompiled, it's just fetched from the cache. This
gives jTDS a 2x performance increase over the next fastest driver in
some (not so uncommon) cases. For example, if you have a method that
inserts a row into a table by creating a <code>PreparedStatement</code>,
using it once and then closing it, your statement will be compiled only
once for each <code>Connection</code>, no matter how many times you
call that method.</p>
<p>The number of statements that are kept open simultaneously can be
controlled with the <code>maxStatements</code> parameter; see the
<a href="#urlFormat">jTDS URL format</a> for more information.</p>
<p>Future versions of jTDS will allow the type of cache (LRU, FIFO, etc)
to be selected.</p>
<p><a href="#">^ top ^</a></p>
<p class="title">TDS Protocol Version</p>
<p class="question"><a name="getConnectionHangs"></a>I'm trying to connect
to SQL Server 6.5, but it hangs when calling <code>getConnection()</code>.</p>
<p>jTDS uses by default TDS 8.0 (which is SQL Server 2000's protocol) to
communicate with the database server. When jTDS sends the 8.0 login request
SQL Server 6.5 doesn't understand it so it returns a 4.2 error (<code>Login
failed</code>). But because jTDS is expecting a TDS 8.0 packet as a response
(not a TDS 4.2 packet) it doesn't properly understand the response packet
and it hangs waiting for more data from the server. The solution is to set
the <code>"TDS"</code> property to <code>"4.2"</code>
(through the URL or <code>Properties</code> object passed to <code>getConnection()</code>
or using the appropriate setter of <code>JtdsDataSource</code>, if you
are using the <code>JtdsDataSource</code>).</p>
<p>For more information about URL format and the properties that may be
passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="longColumnNames"></a>Why do column names more
than 30 characters long, get chopped off at 30 characters?</p>
<p>You are very probably using TDS 4.2 to communicate with the SQL Server.
TDS 4.2 is the protocol used by SQL Server 6.5 and it has the limitations
of SQL Server 6.5 (among which a maximum column name size of 30 characters).
jTDS 0.2 and earlier use TDS 4.2 by default. In order to change that you
have to specify it explicitly in the <code>Properties</code> or the URL
you supply when you create the connection. If you experience this problem
with versions 0.3 or later, then you have specified (in the connection
properties or URL) that TDS 4.2 should be used; remove that setting.</p>
<p>For more information about URL format and the properties that may be
passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
<p><a href="#">^ top ^</a></p>
<p class="question"><a name="imageData4k"></a>jTDS fetches only the first
4Kb of <code>IMAGE</code> data.</p>
<p>You are very probably using TDS 4.2 to communicate with the SQL Server.
TDS 4.2 is the protocol used by SQL Server 6.5 and it has the limitations
of SQL Server 6.5 (among which a maximum size for <code>IMAGE</code> data
of 4Kb). jTDS 0.2 and earlier use TDS 4.2 by default. In order to change
that you have to specify it explicitly in the <code>Properties</code>
or the URL you supply when you create the connection. If you experience
this problem with versions 0.3 or later, then you have specified (in the
connection properties or URL) that TDS 4.2 should be used; remove that
setting.</p>
<p>For more information about URL format and the properties that may be
passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
<p class="question"><a name="connectOmnibus"></a>What do i have to do to connect
to Netcool Omnibus (or any derived Product).</p>
<p>You are required to use TDS 5.0 to communicate with the Omnibus Server and
set a default charset to avoid SQL errors, so your URL will look like:
<code>jdbc:jtds:sybase://NCO:4100;TDS=5.0;charset=iso_1</code>.
Since the Omnibus Server understands only a limited subset of SQL, you cannot
use prepared Statements.
</p>
<p><a href="#">^ top ^</a></p>
<p class="title">Technical support</p>
<p class="question"><a name="techSupport"></a>Is there any commercial
technical support available for jTDS?</p>
<p>For the moment you can get official technical support from individual
developers of jTDS; contact any of us and we'll be happy to provide you
with our tech support terms and conditions. Of course, we will keep
offering support on our SourceForge forums just as we did until now; we
are only trying to encourage adoption of jTDS, not make a fortune out
of it.</p>
<p>As for where the technical support money will go, part of them will be
retained by the developer and part of them will go back into jTDS.
Currently the aim is to raise US $2000, to pay for JDBC certification.
We're 100% sure jTDS will pass the certification test suite, we just
need the money for it. To this end, we also accept donations.</p>
<p><a href="#">^ top ^</a></p>
<p class="title">Other</p>
<p class="question"><a name="other"></a>I didn't find the answer to my
problem in this FAQ. What should I do?</p>
<p>If you need help with any other jTDS-related issue, search the
<a href="http://sourceforge.net/forum/forum.php?forum_id=104389">Help
forum</a> first and if you still don't find anything, post a question.
It will usually get answered within 24 hours. One thing, though: please
register as a SourceForge member and log in if you haven't done so yet,
so you can be automatically notified of updates to the questions you
post.</p>
<p>If you encountered an issue that you have tested and retested and you're
sure it's a bug, use the Bugs link on top of the page. Again, make sure you
are a SourceForge member AND that you are logged in when you post.
<p><a href="#">^ top ^</a></p>
<!--
==================================
Content ends here
==================================
-->
</td>
<td width="9" background="images/mainr.gif"><img src="images/spacer.gif"></td>
</tr>
<tr>
<td width="9" height="9"><img src="images/mainbl.gif" width="9" height="9"></td>
<td height="9" background="images/mainb.gif"><img src="images/spacer.gif"></td>
<td width="9" height="9"><img src="images/mainbr.gif" width="9" height="9"></td>
</tr>
<tr>
<td colspan="3">
<table border="0" cellspacing="0" width="100%" class="outer">
<tr>
<td class="copyright" width="150">
Project hosted by<br><br>
<A href="http://sourceforge.net/projects/jtds" target="_top"><IMG src="http://sourceforge.net/sflogo.php?group_id=33291&type=2" border="0" alt="SourceForge Logo" class="otherLogo"></A><br>
</td>
<td class="copyright" width="500">WebRing member<br><br>
<script language=javascript src="http://ss.webring.com/navbar?f=j;y=alin_sinpalean;u=10063174"></script>
<noscript><center><table bgcolor=gray cellspacing=0 border=2 bordercolor=red>
<tr><td><table cellpadding=2 cellspacing=0 border=0><tr><td align=center>
<font face=arial size=-1>This site is a member of WebRing.
To browse visit <a href="http://ss.webring.com/navbar?f=l;y=alin_sinpalean;u=10063174">
here</a>.</font></td></tr></table></td></tr></table></center></noscript>
</td>
<td class="copyright" width="150">
Web Design<br><br>
<a href="http://anca13.go.ro" class="outer">Anca Sinpalean</a>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
|