I'm getting different results from sasql_affected_rows() with sasql_query() vs sasql_stmt_execute() and I can't see what I'm doing wrong. (I use sasql_stmt_execute() because I use prepared statements.)
After sasql_query, I get the proper number of rows, while after sasql_stmt_execute, the affected rows are always zero. Here's my test code:
$cstring = "DSN=demo16;UID=DBA;PWD=sql"; $sql = "UPDATE Customers SET ID = ID;";
and the output is:
sasql_query() UPDATE Customers SET ID = ID; sasql_affected_rows()=126 sasql_stmt_execute() UPDATE Customers SET ID = ID; sasql_affected_rows()=0
Has anyone else seen this?
asked 03 Nov '14, 16:18
The function you need to use for the sasql_stmt_execute() case is a different one
Calling sasql_affected_rows() is picking up the result set from the connection object and thus the last query.
Hopefully this will make this a little clearer.
answered 01 Dec '14, 16:01
Nick Elson S...
Maybe I missed something important but the operation
by definition makes no changes. In SQL anywhere that will always affect 0 rows, and will not even get logged.
The difference here is that the sasql_stmt_execute() execution only performs the update (thus rowcount==0) where as the sasql_affected_rows() execution returns the result set of candidate rows (thus a rowcount >0).
This difference is because of a new feature introduced in version 12.0 documented as "Support for selecting from DML statements" . Look to the 3rd from last item near the bottom.