FreeTDS Development Group

[Dylan Kucera <djkucera AT sympatico.ca>]

Hello FreeTDS enthusiasts,

I recently started using FreeTDS (freetds-0.83.dev.20110306) as an
ODBC driver for Oracle Heterogeneous Service (11.1) to be able to
communicate from an Oracle Database Link to a SQL Server 2005
instance.  I've run into a concerning problem that shows up when
FreeTDS is configured to run with TDS 8.0 but not when configured to
run 7.0.  I'm worried that the problem might show up anyway in some
other situation even with protocol version 7.0.

Aside from configuring the Oracle Heterogeneous Services links, the
use case that causes a problem is rather simple:  Attempt to compile
this small test procedure on the Oracle side:

create or replace procedure admin.Test_FreeTDS is

tOwner VARCHAR2(256);

begin

       SELECT "name"
       INTO tOwner
       FROM sys.all_parameters@rms_simulation;
  
end Test_FreeTDS;

Using TDS 8.0, it errors out, TDS 7.0 it compiles.

I have created TDS Dump traces for both situations, and archived them
in a RAR that I have broken into 3 pieces under 75K each.  Since I'm
not sure if the mailing list limit is one 75K attachment per e-mail or
per attachment, I'll play it safe and upload 3 different e-mails.  So
as to reduce the size of these monstrous trace files, I removed the
middle part of the lengthy sections that repeat many times:

token.c:2300:tds_process_row(): reading column 2
token.c:2045:tds_get_data: type 56, varint size 0
token.c:2106:tds_get_data(): wire column size is 4
...repeat many times...

Note that I did not remove the entire segment in any case, and
everything that was removed was replaced with the text [Chunk
removed].

From what I can tell, the problem appears to be that FreeTDS is
routinely calling "sp_unprepare 0" when configured to run with TDS
protocol version 8.0, and 0 is not a valid statement handle,
and so the error "[FreeTDS][SQL Server]Could not find prepared
statement with handle 0." is being raised.  I briefly thought about
creating a hack to quietly move along if an attempt to close handle 0
was made, but then I quickly realized that this would likely lead to
other problems including handle leaks, memory leaks... etc.

Because I'm making a call to go ahead into a production setting with
version 7.0 of the protocol configured, I'm hoping someone can provide
me some comfort that the 7.0 trace file is showing a healthy process.
What would be an extra bonus would be taking a look at the version 8.0
trace file to identify what is causing the failure and letting me know
if it can be fixed.

Thank you for the driver, reading my e-mail, and for your assistance!
Dylan.