Batches and row counts

auto batch_support=conn->config_get_batch_support();
bool select_explicit=batch_support->count("SQL_BS_SELECT_EXPLICIT");
bool row_count_explicit=batch_support->count("SQL_BS_ROW_COUNT_EXPLICIT");
bool select_proc=batch_support->count("SQL_BS_SELECT_PROC");
bool row_count_proc=batch_support->count("SQL_BS_ROW_COUNT_PROC");

int memo_id;
std::string memo_code;

auto stmt=conn->prepare("DELETE FROM memotbl WHERE memo_id=?;"
                        "UPDATE memotbl SET printed=1 WHERE memo_code=?;"
                        "SELECT memo_text FROM memotbl WHERE printed=1");

stmt->execute(memo_id, memo_code);

size_t rows_deleted=stmt->row_count();


size_t rows_updates=stmt->row_count();


std::string memo_text;

while (stmt->fetch("memo_text", memo_text))
   // ...

Most database drivers support SQL batches (executing more than one SQL statement at a time). Use config_get_batch_support() to verify whether the database driver supports SQL batches with SELECT statements, or other SQL statements that update or delete rows (except when they're not).

row_count() returns the number of rows modified by the executed non-SELECT SQL statement (an UPDATE or a DELETE). When the executed SQL contains more than one statement, the first call to row_count(), fetch(), or fetch_vectors() reports the results of the first statement in the batch. Use more() to advance to the next statement in the batch(). Afterwards, row_count(), fetch(), and fetch_vectors() use the results of the next statement in the batch.

more() returns true if the statement succeeds, or false if there are no more statements in the batch. Semantics of error handling depend on the database driver. Some database drivers throw an exception from execute() if any statement in the batch had an error. Other database drivers throw an exception from execute() if the first statement in the batch had an error, and more() throws an exception if the next statement in the batch had an error. If the executed statement contains a batch, this means that a thrown exception from execute() (and perhaps execute_vector() as well) and more() still leaves the statement object in a usable state for additional calls to more().

It also means that the SQL batch must be explicitly prepare()d, in order to obtain the statement handle; then executed. Invoking execute() on a connection object, with an implicit prepare() means that the statement handle will not be available if execute() throws an exception.