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: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] DBD::ODBC (0.45), MS SQL, unixODBC, FreeTDS (CVS), bind_param_ino ut
  • Date: 31 Dec 2002 00:01:29 +0100

Il lun, 2002-12-30 alle 23:17, James K. Lowden ha scritto:
> 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,
>

James... are you back from vacation? I think so... :)

0xA1 is processed with default_tokens cause is processed during cancel
operation. Using TDS7 solve problem but problem with 4.2 still remain...

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page