FreeTDS Development Group

[crawford charles <fiducianettestz AT yahoo.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...

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.


on Tue, 2 Jan 2007 17:38:10 +0100, "ZIGLIO, Frediano, VF-IT"  wrote (in 
FreeTDS Digest, Vol 48, Issue 1, Message: 4):

> On 
 Tue, 2 Jan 2007 08:06:34 -0800 (PST), crawford charles wrote: 

> 
> Can I assume that only one ROWFMT is "active" at a time?

No, every cursor can have a different format and there are normal rows
too.

> Can I assume that if the PARAMFMT does not immediately 
> precede a PARAMS, I should use the PARAMFMT supplied with the 
> most recent CURDECLARE?
> 

I think not, you can have multiple cursors active. This is the good
thing with cursors (but I have to admit the worst for tracing)

> Thanks for any information.
> 
> (still no news on "SQL Anywhere CMDSEQ"?)
> 
> C.
> 

bye
  freddy77





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