Documentation Source Text

<p>If the xUpdate method violates some constraint of the virtual table
(including, but not limited to, attempting to store a value of the wrong 
datatype, attempting to store a value that is too
large or too small, or attempting to change a read-only value) then the
xUpdate must fail with an appropriate [error code].

<p>If the xUpdate method is performing an UPDATE, then
[sqlite3_value_nochange(X)] can be used to discover which columns
of the virtual table were actually modified by the UPDATE
statement.  The [sqlite3_value_nochange(X)] interface returns
true for columns that do not change.
On every UPDATE, SQLite will first invoke
[xColumn] separately for each unchanging column in the table to 
obtain the value for that column.  The [xColumn] method can
check to see if the column is unchanged at the SQL level
by invoking [sqlite3_vtab_nochange()].  If [xColumn] sees that
the column is not being modified, it should return without setting 
a result using one of the [sqlite3_result_int|sqlite3_result_xxxxx()]
interfaces.  Only in that case [sqlite3_value_nochange()] will be
true within the xUpdate method.  If [xColumn] does
invoke one or more [sqlite3_result_int|sqlite3_result_xxxxx()]
interfaces, then SQLite understands that as a change in the value
of the column and the [sqlite3_value_nochange()] call for that
column within xUpdate will return false.

<p>There might be one or more [sqlite3_vtab_cursor] objects open and in use 
on the virtual table instance and perhaps even on the row of the virtual
table when the xUpdate method is invoked.  The implementation of
xUpdate must be prepared for attempts to delete or modify rows of the table
out from other existing cursors.  If the virtual table cannot accommodate
such changes, the xUpdate method must return an [error code].