Skip to Content.
Sympa Menu

freetds - [freetds] SQLRowCount failing after prepare and execute

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Matthew A. Davis" <azami AT speakeasy.net>
  • To: freetds AT lists.ibiblio.org
  • Subject: [freetds] SQLRowCount failing after prepare and execute
  • Date: Thu, 12 Feb 2004 16:28:14 -0500

When I send an UPDATE using SQLExecDirect(), then check the number of
affected rows, all is fine. When I send the same command using SQLPrepare()
and SQLExecute(), checking the number of effected rows fails with SQLState
24000 (Invalid Cursor).

I've made my test code available on the web:
http://www.speakeasy.org/~azami/code/
In addition to the .cpp file, I've included tdsdump logs for the two cases.

Basically, after connecting and getting a statement, I'm doing this:

SQLPrepare(hstmt, (SQLCHAR *)("UPDATE SQLDEV1.OT_LastRecordID SET RecordID =
RecordID + 1"), SQL_NTS);
SQLExecute(hstmt);
SQLRowCount(hstmt, &rows);

In this case SQLRowCount fails. If I SQLExecDirect() the exact same
statement:

SQLExecDirect(hstmt, (SQLCHAR *)("UPDATE SQLDEV1.OT_LastRecordID SET RecordID
= RecordID + 1"), SQL_NTS);
SQLRowCount(hstmt, &rows);

then SQLRowCount succeeds and returns the correct number.

The OT_LastRecordID table has one column, RecordID, which is an integer. It
has one record.

Looking at the freeTDS source, I see that SQLRowCount() returns this error if
stmt->dbc->current_statement != stmt. I've verified that this is what's
happening by returning more info with the error. current_statement is NULL.

_SQLExecute() sets current_statement in the middle (odbc.c line 2379), then
if tds_process_result_tokens() returns TDS_NO_MORE_RESULTS, it resets
current_statement to NULL (line 2441). It looks like the count is being
invalidated when the DONEPROC result token is processed; when we call
SQLExecDirect, a DONE token is processed instead.

We are using FreeTDS 0.62.1 on Linux, against SQL Server Personal Edition
8.00.760 (SP3) running on Windows 2000. The database is set for
compatibility level 80.

Any idea why this is happening? Is this a bug in FreeTSD, or a problem in
our configuration? I'm quite surprised no one else seems to have encountered
this - at least, I wasn't able to find any posts about it through Google or
the freetds mailing list archive.

Thanks in advance for any help.

--
Matthew A. Davis ( mailto:azami AT speakeasy.net )
http://www.speakeasy.net/~azami

"It's not always popular upholding the Constitution,
but it's always the right thing to do."
-Senator Patrick J. Leahy (D-Vt)




Archive powered by MHonArc 2.6.24.

Top of Page