FreeTDS Development Group

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

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > > > net.c:542:Received packet
> > > > 0000 fd 30 00 02 00 d1 04 00-00                      
> |.0...... .|
> > > > 
> > > > token.c:1920:processing row.  column size is 253
> > > 
> > > That "fd 30 00" means "end of result set (fd), "results 
> > > cancelled (30)".  
> > > 
> > 
> > Mumble mumble... it seems that client part is still 
> expecting row data
> > while server send cancel acknowledge... it would be helpful to see
> > previous packet header. Perhaps server stop sending row informations
> > just sending an empty packet with last flag set to 1 ??
> 
> Well, it's a mistake for the client to expect row data after 
> the server
> sends that cancel acknowledgement.  
> 
>       Cancel -->
>       <-- data
>       <-- data
>       <-- data
>       <-- End of Results, results cancelled 
>       [state == idle]
> 

yes, but how does the client know that the server is sending acknowledge
and not just data cause it have still to receive our cancel? Client
correctly send cancel and start parsing data normally (but discarding
rows and similar). When it receive cancel acknowledge it pass status to
idle and reset TDSSOCKET cancel flag. From dump we saw a packet which
contains only the acknowledge but it seems that client is still handling
row data so it parses the acknowledge as a normal column data. Perhaps
for long resultset server stops sending row data setting last_packet
flags in header and than send the aknowledge in a different packet??
This is why I asked to see previous packet...

Well... perhaps I can reproduce it...

> Looking at net.c::tds_read_packet(), maybe we should set 
> tds->last_packet
> = 1 when the cancelled bit is set in the packet header?  
> 

freddy77