DB-Library’s DBCOUNT returns the number of rows affected by the current server command. DBCOUNT is called in the dbresults loop, after all rows are retrieved (if any).
In Client-Library, ct_res_info(CS_ROW_COUNT) returns the number of rows affected by the current server command. As with DBCOUNT, the ct_res_info gives a row count of -1 when the command is one that never affects rows.
The following fragment demonstrates the use of ct_res_info to get a row count. This fragment executes in the ct_results loop, under the case where result_type is CS_CMD_DONE:
CS_INT rowcount;
...
ret = ct_res_info(cmd, CS_ROW_COUNT, (CS_VOID *)&rowcount,
CS_UNUSED, NULL);
EXIT_ON_FAIL(context, ret, "ct_res_info(CS_ROW_COUNT) failed.");
if (rowcount != -1)
printf(“(%ld rows affected)\n”, rowcount);
DBCOUNT and ct_res_info(CS_ROW_COUNT) are nearly equivalent, both returning the number of rows affected by the current command. There is one important difference in behavior when the current command is one that executes a stored procedure:
DBCOUNT returns the number of rows affected by the last select statement executed by the stored procedure.
For example, if the last two statements executed by the procedure are select and update statements, DBCOUNT returns the number of rows affected by the select, not by the update.
ct_res_info(CS_ROW_COUNT) returns the number of rows affected by the last statement that could affect rows executed by the stored procedure.
For example, if the last two statements executed by the procedure are a select statement and an update statement, ct_res_info(CS_ROW_COUNT) returns the number of rows affected by the update.
If your DB-Library application depends logically on DBCOUNT’s behavior after executing a stored procedure, then you must change the program logic when converting the application to Client-Library.
