FreeTDS Development Group

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

> 
> ZIGLIO, Frediano, VF-IT a écrit :
> > Hi,
> >   finally I got some time to work seriously on FreeTDS.
> > 
> > Currently there is no open bug at project site. 
> 
> Hi, I just wanted to make you lie :)
> I have generated a full tds logfile for the problem I'm having,
> however this time I didn't get a freeze but an error.
> (see tracker)
> 
> Christophe
> 

Finally I got the full log !!!

And I got it !!!

>From log:

...

net.c:673:Sending packet
0000 06 01 00 08 00 00 00 00-                        |........|

...

net.c:446:Received header
0000 04 03 01 fc 00 00 00 00-                        |........|

...

net.c:446:Received header
0000 04 01 00 11 00 00 00 00-                        |........|

net.c:542:Received packet
0000 fd 30 00 02 00 14 47 00-00                      |.0....G. .|



The key is

net.c:446:Received header
0000 04 03 01 fc 00 00 00 00-                        |........|

note that status is 3 (second byte)... never seen before in all my FreeTDS 
works (that is in 5 years !!!)
This means: "ok, these are still results but I received acknowledge so this 
is the last"... so the right behavior is reset state to idle or pending 
without data... !!!
The implementation problem is that lower level (network level in libTDS) 
should communicate to token level to handle this case...
I find this stuff fantastic. Assume that you are getting a very long column 
(say a 500kb image) the server just stop sending image setting correctly 
state. I don't understand why newer server do not seem to use this feature...

freddy77