Re: problem with ct_dynamic(....CS_PREPARE...) against SQL Server 2005

[email protected] wrote:
> But the issue
> here is that I relinguish control to the freetds library by calling
> ct_results(). It calls the tds library to process the various result
> tokens and only returns control to me after all 6 result token have been
> processed at the tds level. And because the last token does not contain
> row count information, the row count information from earlier tokens
> that I am interested in gets overwritten and I can not retrieve it
> anymore with ct_res_info(). 

Now I see your point.   It's frustrating because you see rowcount
information and can't get to it, but there's no general API-level
solution.  

Here's a stored procedure:

	create procedure p as 
		select * into #t from systypes 
		delete #t 
		select min(name) from systypes

It returns no rowcount.  Before it returns, the server sends two
DONEINPROC packets with 34 rows affected and one with 1 row affected. 
What is the  rowcount this stored procedure?  1? 34? 69?  

We cannot say, in general, that the last rowcount (1) is any more useful
or correct or representative than any of the other answers.  The server
and the library choose instead to "summarize" with a final DONE packet
that says there's no valid rowcount.  

I haven't done a lot of ct-lib programming.  AFAIK, though, you can only
get one rowcount per ct_results(), and the above procedure will produce
only one resultset.  The general solution -- one that works with all APIs
and servers -- is to bump the problem up to the application: have the
stored procedure return the rowcount in an output variable or as a return
status.  

Regards, 

--jkl