Skip to Content.
Sympa Menu

freetds - RE: [freetds] Concurrent result sets

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Concurrent result sets
  • Date: Tue, 29 Jul 2003 10:23:00 +0100

Hi John,

Yes, I guess you could say that this is a limitation of the TDS protocol.
The protocol (at a very very simple level) works as follows:

1) client sends command to SQL server (a SQL statement for example)
2) SQL server sends results to client

Consider the case where the Client sends a SQL "select" to the server which
retrieves many rows.
The server sends back down the wire some result set meta data (describing
the result set - datatypes etc.), followed by all the results of the query.

When a client does a "fetch" of the results using whichever API (dblib with
dbnextrow, etc.) The client is reading the results from the wire.
In most cases (BIG caveat follows) the "fetch" of a data row does not
involve any further interaction with the server, it simply reads the next
chunk of data from the wire.
Microsoft sometimes refer to this interaction as a "firehose" - the client
is "hosed" with the results of the command, which it must then process.
When we talk about not allowing more than one active result set per
connection, what we're saying is that the client has to finish processing
the data that has been "hosed" down to it, before it can send another
command.

The BIG caveat I mentioned, and I notice that Freddy has referred to, is
cursors.
With cursor operations, the client can "fetch" data from the server in small
chunks.

So, the client would open a cursor, sending a query to the server.
Each subsequent "fetch" is then an atomic "call-response" with the server,
you tell the server how many rows to fetch, and the server sends just that
number of rows.

This leaves the connection open to take other commands, whilst the first
resultset is still "open".

Hope this explains things.


Bill

> -----Original Message-----
> From: John Anderson [SMTP:ardour AT semiosix.com]
> Sent: 29 July 2003 10:09
> To: FreeTDS Development Group
> Subject: [freetds] Concurrent result sets
>
> This is somewhat off-topic, but I'm not sure where else I can find an
> answer to this question. urls welcome ;-)
>
> According to some MS docs I read, the win32 MS SQL Server ODBC driver
> does not allow more than one active result set per connection. If I
> understood correctly, this is a limitation of the underlying TDS
> protocol. Is this the case?
>
> All information gratefully received.
>
> thanks
> John
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds





Archive powered by MHonArc 2.6.24.

Top of Page