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

Try applying this patch. If you are not able to apply it tell me and I'll 
send a new package.

freddy77

Attachment: vedi.diff
Description: vedi.diff