Re: Intersolv SQLRowCount() bug?

jowi@my-dejanews.com wrote: > > Hi, > Environment: Intersolv ODBC 3.11 (EVAL) / Informix 7.2-NT > An attempt to rephrase my question of last week. > > On a simple table > CREATE TABLE a (i SMALLINT, j CHAR(1))> a simple update on a row is performed through prepare/bind/execute > UPDATE a SET j='b' WHERE i=?> after which the rowCount is retrieved (correctly) using SQLRowCount(). > > Then we re-bind the parameter and re-execute the prepared stmt. > If the 2nd update does not match any rows, the SQLRowCount() reported > is the one from the earlier SQLExecute() instead of the expected 0. Probably the dataset (hstmt) is not closed but reflects the total of the two updates. The SQLFreeStmt options are: SQL_ CLOSE: Close the cursor associated with hstmt (if one was defined) and discard all pending results. The application can reopen this cursor later by executing a SELECT statement again with the same or different parameter values. If no cursor is open, this option has no effect for the application. SQL_DROP: Release the hstmt, free all resources associated with it, close the cursor (if one is open), and discard all pending rows. This option terminates all access to the hstmt. The hstmt must be reallocated to be reused. SQL_UNBIND: Release all column buffers bound by SQLBindCol for the given hstmt. SQL_RESET_PARAMS: Release all parameter buffers set by SQLBindParameter for the given hstmt. You may also have to do a SQLTransact(hstmt, SQL_COMMIT) or rollback to see the effect of a particular update alone. Note: some database drivers also drop the hstmt on SQL_COMMIT or SQL_ROLLBACK (see SQLGetInfo with SQL_CURSOR_COMMIT_BEHAVIOUR or SQL_CURSOR_ROLLBACK_BEHAVIOUR). AriL -- Humans may send email (if absolutely necessary) to the obvious non-spam address.