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(); stmt->more(); size_t rows_updates=stmt->row_count(); stmt->more(); 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.