Count The Number Of Rows Modified

From 18657a960e125336f704ea058e25c27bd3900dcb Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 5 May 2024 19:28:19 +0200 Subject: Adding upstream version 3.40.1. Signed-off-by: Daniel Baumann --- www/c3ref/changes.html | 186 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 www/c3ref/changes.html (limited to 'www/c3ref/changes.html') diff --git a/www/c3ref/changes.html b/www/c3ref/changes.html new file mode 100644 index 0000000..cc7b09a --- /dev/null +++ b/www/c3ref/changes.html @@ -0,0 +1,186 @@ + + + + + +Count The Number Of Rows Modified + + + +

+ +

+Small. Fast. Reliable.
Choose any three. +

+ + +

+ +

+ + +

SQLite C Interface

Count The Number Of Rows Modified

+int sqlite3_changes(sqlite3*);
+sqlite3_int64 sqlite3_changes64(sqlite3*);
+

+These functions return the number of rows modified, inserted or +deleted by the most recently completed INSERT, UPDATE or DELETE +statement on the database connection specified by the only parameter. +The two functions are identical except for the type of the return value +and that if the number of rows modified by the most recent INSERT, UPDATE +or DELETE is greater than the maximum value supported by type "int", then +the return value of sqlite3_changes() is undefined. Executing any other +type of SQL statement does not modify the value returned by these functions.

+ +

Only changes made directly by the INSERT, UPDATE or DELETE statement are +considered - auxiliary changes caused by triggers, +foreign key actions or REPLACE constraint resolution are not counted.

+ +

Changes to a view that are intercepted by +INSTEAD OF triggers are not counted. The value +returned by sqlite3_changes() immediately after an INSERT, UPDATE or +DELETE statement run on a view is always zero. Only changes made to real +tables are counted.

+ +

Things are more complicated if the sqlite3_changes() function is +executed while a trigger program is running. This may happen if the +program uses the changes() SQL function, or if some other callback +function invokes sqlite3_changes() directly. Essentially:

+ +

Before entering a trigger program the value returned by +sqlite3_changes() function is saved. After the trigger program +has finished, the original value is restored.
+ +
Within a trigger program each INSERT, UPDATE and DELETE +statement sets the value returned by sqlite3_changes() +upon completion as normal. Of course, this value will not include +any changes performed by sub-triggers, as the sqlite3_changes() +value will be saved and restored after each sub-trigger has run. +

+ +

This means that if the changes() SQL function (or similar) is used +by the first INSERT, UPDATE or DELETE statement within a trigger, it +returns the value as set when the calling statement began executing. +If it is used by the second or subsequent such statement within a trigger +program, the value returned reflects the number of rows modified by the +previous INSERT, UPDATE or DELETE statement within the same trigger.

+ +

If a separate thread makes changes on the same database connection +while sqlite3_changes() is running then the value returned +is unpredictable and not meaningful.

+ +