FreeTDS Development Group

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

On Sat, 06 Mar 2004 12:37:11 +0100, Frediano Ziglio <freddyz77 AT tin.it>
wrote:
> ?? store procedure ??
> I think there are two problems. I understood row count problem, but I
> don't know store procedure one... You patch was about SQLRowCount, I
> don't understand where store procedure problems stand..

Yes, there are two problems.  

SQLRowCount() in 0.62.1 fails almost every time.  When SQLMoreResults()
sees TDS_NO_MORE_RESULTS, it sets stmt->dbc->current_statement = NULL.  If
SQLRowCount() is called after that (which is perfectly legitimate), it
sees stmt->dbc->current_statement != hstmt and returns a failure.  Even
though there's no error.  

The second problem is that real errors aren't propogated back to the user.
 To illustrate, modify the stored procedure in
src/odbc/unittests/transaction.c:

        Create Procedure testinsert 
                @value int
        As
        insert into TestTransaction values ( @value )
        select * from TestTransaction
        insert into TestTransaction values ( 'b' )

You will see the 0xAA error packet come back from the server, but
SQLExecDirect() will not return an error to the caller.  

> > To me, it has nothing to do with "rows affected", which, although
> > interesting, is not critical.  What's critical is to be able to call
> > stored procedures and be made aware of any errors transmitted by the
> > server.  
> > 
> 
> It's critical for Perl users, cause DBI::ODBC call SQLRowCount after
> SQLExecDirect/SQLExecute.

That's how I found the problem; I'm using DBD::ODBC.  I don't rely on row
counts, but I do check for errors.  My script was failing because I was
getting an error from SQLRowCount().  Now it's working, but won't detect
errors, which isn't much better.  

--jkl