FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Chris McDaniel [mailto:Chris.McDaniel AT telus.com]
> Sent: January 2, 2003 10:09 AM
> 
> It looks like result sets
> are coming back OK now which is great

Good! :)  

> looks like I'm missing output where
> the stored proc uses the (T-SQL) 'print' statement.  

A "print" statement's output would be passed as an out-of-band
server-originated message, not as data, similar to the "Changed language
setting to us_english." message you may see when you log on.  One small
difference: "print" statement messages have a "message number" of zero.  

In db-lib, the client provides a "message handler" callback function that
the library invokes whenever a server message arrives.  I don't know how
that's done in ODBC, or how well we support it.  

tsql used to ignore them; I just committed a change to print them instead.  

--jkl

> 
> Thanks,
> 
> Chris
> 
> -----Original Message-----
> From: James K. Lowden [mailto:jklowden AT schemamania.org]
> Sent: January 1, 2003 9:11 PM
> To: freetds AT lists.ibiblio.org
> Subject: Re: [freetds] DBD::ODBC (0.45), MS SQL, unixODBC, FreeTDS
> (CVS), bind_param_ino ut
> 
> 
> On Wed, 1 Jan 2003 09:00:25 -0700, "Chris McDaniel"
> <Chris.McDaniel AT telus.com> wrote:
> > 
> > I got a fresh cvs checkout, recompiled and tried it again. 
> > Unfortunately I cannot use tdsver 7.0 as it is an MS SQL 
> 6.5 server and
> > I get login failure if I try higher tds versions (and a 
> core dump).  As
> > before, I still get no results back from the proc.  
> 
> Chris:  Does "no results back from the proc" mean no result 
> set (no data)
> or no return code?
> 
> Frediano:  Our return code processing is broken in ct-lib; it may be
> affecting ODBC, too.    
> 
> I thought we needed a unittest for return code processing, so 
> I modified
> src/ctlib/unittests/t0002.c.  It calls "exec sp_who" and 
> prints the result
> set and the return code status (which of course should always 
> be zero for
> sp_who).  
> 
> I'm no ct-lib maven; I just tried to follow instructions and 
> rely on the
> rest of the unittests for examples.  AFAICT, I've coded it 
> correctly, but
> ct_results() fails to retreive the return code. 
> tds_process_result_tokens() does not place the return code in 
> the buffer
> provided by ct_bind(), so the return code cannot be retrieved with
> ct_fetch().  
> 
> The sequence of events:
> 
> 1.  sp_who result set arrives and is processed normally (7 columns).
> 2.  ct_results() is called again.  
> 3.  TDS_RETURNSTATUS_TOKEN (0x79) arrives.  
> 4.  tds_process_result_tokens() records the status in the 
> TDSSOCKET and
> returns a type 4043.  It should do more: set the column count 
> and create
> the row.  
> 5.  ct_results() returns CS_STATUS_RESULT, indicating a status row is
> available.  
> 6.  t0002.c calls ct_describe(), which says there are (still) 
> 7 columns, a
> lie.  
> 7.  t0002.c calls ct_fetch().  It doesn't know it's supposed 
> to return a
> status row.  It calls tds_process_row_tokens() and returns CS_END_DATA
> without returning any rows.  
> 
> Nota Bene.  Other recent logs have shown 
> TDS_RETURNSTATUS_TOKEN markers
> arriving from a TDS 8.0 server when *no* stored procedure was 
> executed. 
> Return code processing will have to tolerate that.  We'll 
> have to set up
> the rows for retrieval and discard them if they're not requested.  
> 
> HTH.
> 
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.