FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
>   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 ??
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 
> preceeded 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.

freddy77