FreeTDS Development Group

[Simon Matthews <sam AT knowledgepool.com>]

James Lowden Wrote:


> Yours is a plausible explanation.  Without seeing the source 
> code and a log of the session, it's hard to say for sure.  
> 
> TDS is half-duplex protocol.  The client libraries maintain 
> state information i.e., they keep track of whether the server 
> is expecting something from the client or vice versa.  
> 
> The error message actually means -- and this is very 
> important -- that the server has not yet indicated it is 
> finished replying.  It might or might not have more data to 
> send, but the client has not yet seen the DONE packet that 
> tells it the server is ready for the next request.  
> 
> With FreeTDS, the client must always check for pending 
> results to every query, even if none are anticipated.  That's 
> how the API is specified, even though some versions of the 
> vendors' libraries tolerate not checking in some circumstances.  
> 
> If the problem is related to cancellation, it's certainly 
> possible that the message could stem from the client not 
> reading "en route" data. After sending the cancel request, 
> the client is obliged to read any rows the server continues 
> to send until the DONE packet arrives (which the client 
> library will represent as NO_MORE_RESULTS or similar).  
> 

I have also seen this in SQL server connections when a stored procedure is
returning result sets when the client is only expecting and handling one.  

HTH 

S