Skip to Content.
Sympa Menu

freetds - Re: [freetds] DBD::ODBC (0.45), MS SQL, unixODBC, FreeTDS (CVS), bind_param_ino ut

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] DBD::ODBC (0.45), MS SQL, unixODBC, FreeTDS (CVS), bind_param_ino ut
  • Date: Mon, 30 Dec 2002 17:17:05 -0500

On Sun, 29 Dec 2002 08:33:58 -0700, "Chris McDaniel"
<Chris.McDaniel AT telus.com> wrote:
>
> Hello,
>
> I was hoping that someone could help me out with my stored procedure
> problems...
[...]
> and the driver trace below - shows that certain values are coming back -
>
>
> Can anyone tell me what I'm doing wrong? Why don't I get the output?
>
> Thanks,
> Chris
>
> Starting log file with debug level 99.
> 2002-12-27 17:30:04.500260 Connecting addr 142.178.18.4 port 1433 with
> TDS version 4.2
[...]
>
> 2002-12-27 17:30:05.233164 inside tds_process_default_tokens() marker is
> a1 Unknown marker: 161(a1)!!
> SQLFreeHandle(2, 0x1f5758)
> SQLFreeHandle(1, 0xf0750)

Chris,

I don't know that anyone has tested return codes in ODBC with TDS 4.2.
You might want to try TDS 7.0, but the situation is a little complicated.


Analysis follows.

Looking at the code, it appears that the 0xA1 token -- a 4.2-only
TDS_COLFMT token, cf. http://www.freetds.org/tds.html -- is apparently not
being anticipated after an 0xA0 (TDS_COLNAME) token. The reason seems to
be that the 0xA0 is being handled by tds_process_default_tokens(), which
it should not be.

According to the comments, in TDS 4.2 TDS_COLNAME and TDS_COLFMT tokens
should always arrive as a successive pair -- never one without the other.
The procedure that handles this pair is tds_process_result_tokens(),
called after tds_submit_query().

Where do we go wrong? It looks like tds_process_result_tokens() is called
as it should be, but receives an 0x7C (TDS_PROCID) prior to the
TDS_COLNAME. Unfortunately, it doesn't know what to do with a TDS_PROCID,
so it passes control to tds_process_default_tokens(), who in turn fails to
process the result set. :-(

Now for a completely unwarranted bit of speculation. If memory serves,
Microsoft servers have an option to transmit the proc_id of a stored
procedure ahead of its results. I bet you have that option turned on
(it's normally off). I wonder if by turning it off, your return code
processing will spontaneously start working.

If so, we can add TDS_PROCID handling to tds_process_result_tokens(), and
then you can set your option back as it was (is).

Regards,

--jkl





Archive powered by MHonArc 2.6.24.

Top of Page