Skip to Content.
Sympa Menu

freetds - RE: [freetds] return status for ctlib

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] return status for ctlib
  • Date: 03 Jan 2003 10:25:28 +0100

Il gio, 2003-01-02 alle 23:48, Lowden, James K ha scritto:
> > 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
>

Simply ODBC and dblib do not expect a row after STATUS_RESULT, so you have to
discard this row...
Other solution is to more row creation in ctlib (IMHO the best method)

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page