SQLITE3_CHANGES(3) | Library Functions Manual | SQLITE3_CHANGES(3) |
sqlite3_changes
—
sqlite3_changes
(sqlite3*);
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:
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.
December 19, 2018 | NetBSD 9.2 |