Updated: 2022/Sep/29
Please read Privacy Policy. It's for your privacy.
SQLITE3_CHANGES(3) Library Functions Manual SQLITE3_CHANGES(3)
NAME
sqlite3_changes, sqlite3_changes64 - count the number of rows modified
SYNOPSIS
#include <sqlite3.h>
int
sqlite3_changes(sqlite3*);
sqlite3_int64
sqlite3_changes64(sqlite3*);
DESCRIPTION
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.
IMPLEMENTATION NOTES
These declarations were extracted from the interface documentation at
line 2599.
SQLITE_API int sqlite3_changes(sqlite3*);
SQLITE_API sqlite3_int64 sqlite3_changes64(sqlite3*);
SEE ALSO
sqlite3_total_changes(3)
NetBSD 10.99 August 24, 2023 NetBSD 10.99