[freetds] SQLMoreResults and odbc/unittests/rpc.c

Lowden, James K james.k.lowden at alliancebernstein.com
Thu Jul 13 10:41:49 EDT 2006

> From: ZIGLIO, Frediano, VF-IT
> Sent: Thursday, July 13, 2006 4:16 AM
> Well... it seems that all collapse so... I'll collapse results too
> :( I still don't understand why test with osql do not collapse
> select with delete... from moreandcount it seems that it collapse
> select with update...

I understand.  db-lib and ODBC define "resultset" differently, and
db-lib offers no way for the application to fetch more than one rowcount
per SELECT.  

dbresults returns SUCCEED only when TDS7_RESULT arrives.

SQLMoreResults returns SQL_SUCCESS for TDS7_RESULT and for "extra" DONE


	"If the command is one that executes a stored procedure, for
example an exec or remote procedure call, DBCOUNT returns the number of
rows returned by the latest select statement executed by the stored

Microsoft's db-lib docs (no longer on the www) say the same thing.  Too
bad they're not following their own spec: dbcount() doesn't return the
count of the last SELECT statement in a stored procedure; it returns the
count of the *last* statement, SELECT or not.  

So, db-lib *must* "collapse" as you say.  It can return only one
rowcount.  I think we should adhere to Sybase's specification and keep
the rowcount from the SELECT statement i.e., from the first DONE packet
after the last ROW packet.  

For ODBC, we should follow Microsoft's lead, returning intermediate
rowcounts based on DONE packets.  Except for one thing: can we agree
that "resultset" means columns, TDS7_RESULT or similar?  We can call the
other thing an "ODBC rowcount resultset" or something like that.  



The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent responsible
for delivering this message to the intended recipient, any review, dissemination,
distribution or duplication of this communication is strictly prohibited. If you are
not the intended recipient, please contact the sender immediately by reply e-mail
and destroy all copies of the original message. Please note that we do not accept
account orders and/or instructions by e-mail, and therefore will not be responsible
for carrying out such orders and/or instructions.  If you, as the intended recipient
of this message, the purpose of which is to inform and update our clients, prospects
and consultants of developments relating to our services and products, would not
like to receive further e-mail correspondence from the sender, please "reply" to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York,
NY 10105.

More information about the FreeTDS mailing list