FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

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