Small. Fast. Reliable.
Choose any three.
Choose any three.
int sqlite3_changes(sqlite3*);
R-15996-49369:[This function returns 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. ] R-44877-05564:[Executing any other type of SQL statement does not modify the value returned by this function. ]
R-53938-27527:[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. R-09813-48563:[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:
R-43399-09409:[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. ] R-53215-27584:[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. ]
See also the sqlite3_total_changes() interface, the count_changes pragma, and the changes() SQL function.
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.