FreeTDS Development Group

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

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: January 2, 2003 4:22 PM
> 
> Il gio, 2003-01-02 alle 21:58, Lowden, James K ha scritto:
> > I think I've corrected ct-lib's return status processing.  
> 
> Yes but this broke ODBC code.
> ODBC do not expect status returned as ROW, only binding result...

What unittest, what line number, did I break?  libtds manufactures the row,
but only ct-lib knows to go looking for it when it sees CS_STATUS_RESULT in
res_type after calling tds_process_result_tokens().  Cf. src/ctlib/ct.c:538.
It sets a flag (row_prefetched) to indicate to ct_fetch that the data are
not to be read from the wire.  Unless that flag is set, ct_fetch() will peek
at the wire, find no pending result set, and return zero rows.  

The logic is quite similar to that for compute rows....

> I don't know dblib... dblib have dbhasretstatus but I don't 
> know how to read value...

When the return status code arrives, libtds parks the value in the
TDSSOCKET.ret_status.  dbretstatus() effectively retrieves it from there.  

+++

I think it's a good strategy to move ancillary data across the API/libtds
boundary as rows, regardless of how the API represents them to the client.
Consider output parameters, for instance.  db-lib returns them one at a time
with dbnumrets() and dbretdata().  ct-lib returns them as a single
CS_PARAM_RESULT row.  ODBC binds them to host variables and lets the
application fetch them from there.  

If libtds adopts the ct-lib way -- essentially, passing labelled results
sets -- the other APIs will have enough infomrmation to do what they need to
do, and benefit from a regular, clean interface.  

--jkl


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.