FreeTDS Development Group

[crawford charles <fiducianettestz AT yahoo.com>]

freddy77,

My apologies for my slow response: digest mode has its limitations (since 
corrected).

Your experience and knowledge are really valuable.  I have been relying on a 
few traces and the Sybase spec to guide me.
Responses in-line.

On Wed Jan 3 at 03:32:41 EST 2007 ZIGLIO, Frediano, VF-IT wrote:

> >   freddy77,
> > 
> > Thanks for the quick reply.
> > 
> > So how would you figure out which PARAMFMT or ROWFMT applies 
> > to the PARAMS, ROW or KEY you am trying to decode?  Obviously 
> > the libraries must be able to figure this out based on their 
> > internal state, but Ethereal would have to infer it based on 
> > the traffic alone...
> > 
> 
> Mmm... PARAMS is not always precedeed by PARAMFMT ??

The spec (version 3.9) states (P. 160):

"A cursor declare statement may be parameterized. If it is, the
description of the parameters is passed to the server using a
TDS_PARAMFMT data stream following the TDS_CURDECLARE data
stream. When the cursor is opened, the parameter values must be
passed to the server with a TDS_PARAMS data stream following the
TDS_CUROPEN data stream. The TDS_CUR_OSTAT_HASARGS status must be
set in this case. that when a client declares a cursor with
parameters, the PARAMFMT follows the CURDECLARE, but the PARAMS
actually follows the CUROPEN."

Of course, they may be talking about the Sybase client libraries,
and somehow made their server software robust enough to handle
"extra" PARAMFMT.
I infer similar behavior for a client CURUPDATE.
("Parameters follow the cursor update token").

If the spec is in error, and the PARAMFMT *always* immediately
precedes the PARAMS, this would eliminate one problem.

> For ROWFMT I think you have to follow the entire flow. I don't know very
> much how ethereal works but I can explain how out library works. When we
> send a cursor command (declare, open, fetch, position, update and so on)
> we set a cur_cursor, when we read the row we check for cur_cursor. We
> have also a current_results that point to proper results (this can be a
> "normal" row, cursor row, compute row or a list of parameters).
> 
> > As for cursors, I had thought that given that there can only 
> > be one "current" (as opposed to "open") cursor at a time, if 
> > I could infer which cursor was "current", and I (somehow) had 
> > associated each cursor with its PARAMFMT.  But that implies 
> > that I would have to track the session from the beginning...  
> > If there is only one "current cursor" then only one 
> > "cursor-associated" ROWFMT is "active".  "Normal" rows do 
> > tend to mess this up, but as far as I know, they only come 
> > from the server, and would "always" (?) be immediately 
> > preceded by a ROWFMT(2).  I had thought that the tricky part 
> > was figuring out the ROWFMT for the KEY from the client.
> > 
> > Thanks again.
> > 
> 
> I don't know if is sufficient to check server data. Surely you have to
> reset current cursor information if last DONE is received but I don't
> know if server send enough information to detect which cursor is
> returning.

You are probably right.

I assume this gets worse if the client uses "language" tokens to
manipulate cursors.  The server responds with a mix of CURINFO,
ROWFMT, ROW, DONE, etc., but I would have no idea what was going
on unless I parsed the SQL.

> 
> freddy77

C



 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com