FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Cedric ROUVRAIS wrote:
> When I execute select @@ROWCOUNT I get
> the correct count that is to say. Why would the rowcount not be
> available ?

The server knows the rowcount after a statement completes.  For
non-SELECT, that's when control returns to the application after
dbsqlexec(). For SELECT, that's after the last row is fetched by client,
when dbnextrow() returns NO_MORE_ROWS.  (That is why @@rowcount is always
right: you can't select @@rowcount until the prior statement completes.)  

Whether or not the rowcount is returned to the client depends on a
connection option: SET NOCOUNT {ON|OFF}.  

If you think db-lib is wrong, that it reports the rowcount as unavailable
when in fact it *is* available, first confirm: using TDSDUMP, see if a
rowcount packet was sent.  

http://www.freetds.org/tds.html#t253

The DONE packet should have the "rowcount valid" bit set, and the rowcount
should be correct.  If both those are true for your packet, dbrows()
should succeed.  

HTH.  

--jkl