** CAPI3REF: Count The Number Of Rows Modified {F12240}**** This function returns the number of database rows that were changed** or inserted or deleted by the most recently completed SQL statement** on the connection specified by the first parameter.  Only** changes that are directly specified by the INSERT, UPDATE, or** DELETE statement are counted.  Auxiliary changes caused by** triggers are not counted. Use the [sqlite3_total_changes()] function** to find the total number of changes including changes caused by triggers.**** A "row changes" is a change to a single row of a single table** caused by an INSERT, DELETE, or UPDATE statement.  Rows that** are changed as side effects of REPLACE constraint resolution,** rollback, ABORT processing, DROP TABLE, or by any other** mechanisms do not count as direct row changes.**** A "trigger context" is a scope of execution that begins and** ends with the script of a trigger.  Most SQL statements are** evaluated outside of any trigger.  This is the "top level"** trigger context.  If a trigger fires from the top level, a** new trigger context is entered for the duration of that one** trigger.  Subtriggers create subcontexts for their duration.**** Calling [sqlite3_exec()] or [sqlite3_step()] recursively does** not create a new trigger context.**** This function returns the number of direct row changes in the** most recent INSERT, UPDATE, or DELETE statement within the same** trigger context.**** So when called from the top level, this function returns the** number of changes in the most recent INSERT, UPDATE, or DELETE** that also occurred at the top level.** Within the body of a trigger, the sqlite3_changes() interface** can be called to find the number of** changes in the most recently completed INSERT, UPDATE, or DELETE** statement within the body of the same trigger.** However, the number returned does not include in changes** caused by subtriggers since they have their own context.**** SQLite implements the command "DELETE FROM table" without** a WHERE clause by dropping and recreating the table.  (This is much** faster than going through and deleting individual elements from the** table.)  Because of this optimization, the deletions in** "DELETE FROM table" are not row changes and will not be counted** by the sqlite3_changes() or [sqlite3_total_changes()] functions.** To get an accurate count of the number of rows deleted, use** "DELETE FROM table WHERE 1" instead.**** INVARIANTS:**** {F12241} The [sqlite3_changes()] function returns the number of**          row changes caused by the most recent INSERT, UPDATE,**          or DELETE statement on the same database connection and**          within the same trigger context, or zero if there have**          not been any qualifying row changes.**** LIMITATIONS:**** {U12252} If a separate thread makes changes on the same database connection**          while [sqlite3_changes()] is running then the value returned**          is unpredictable and unmeaningful.*/int sqlite3_changes(sqlite3*);/*** CAPI3REF: Total Number Of Rows Modified {F12260}***** This function returns the number of row changes caused** by INSERT, UPDATE or DELETE statements since the database handle** was opened.  The count includes all changes from all trigger** contexts.  But the count does not include changes used to** implement REPLACE constraints, do rollbacks or ABORT processing,** or DROP table processing.** The changes** are counted as soon as the statement that makes them is completed ** (when the statement handle is passed to [sqlite3_reset()] or ** [sqlite3_finalize()]).**** SQLite implements the command "DELETE FROM table" without** a WHERE clause by dropping and recreating the table.  (This is much** faster than going** through and deleting individual elements form the table.)  Because of** this optimization, the change count for "DELETE FROM table" will be** zero regardless of the number of elements that were originally in the** table. To get an accurate count of the number of rows deleted, use** "DELETE FROM table WHERE 1" instead.**** See also the [sqlite3_changes()] interface.**** INVARIANTS:** ** {F12261} The [sqlite3_total_changes()] returns the total number**          of row changes caused by INSERT, UPDATE, and/or DELETE**          statements on the same [database connection], in any**          trigger context, since the database connection was**          created.**** LIMITATIONS:**** {U12264} If a separate thread makes changes on the same database connection**          while [sqlite3_total_changes()] is running then the value **          returned is unpredictable and unmeaningful.*/int sqlite3_total_changes(sqlite3*);/*** CAPI3REF: Interrupt A Long-Running Query {F12270}**** This function causes any pending database operation to abort and** return at its earliest opportunity. This routine is typically** called in response to a user action such as pressing "Cancel"** or Ctrl-C where the user wants a long query operation to halt** immediately.**** It is safe to call this routine from a thread different from the** thread that is currently running the database operation.  But it** is not safe to call this routine with a database connection that** is closed or might close before sqlite3_interrupt() returns.**** If an SQL is very nearly finished at the time when sqlite3_interrupt()** is called, then it might not have an opportunity to be interrupted.** It might continue to completion.** An SQL operation that is interrupted will return** [SQLITE_INTERRUPT].  If the interrupted SQL operation is an** INSERT, UPDATE, or DELETE that is inside an explicit transaction, ** then the entire transaction will be rolled back automatically.** A call to sqlite3_interrupt() has no effect on SQL statements** that are started after sqlite3_interrupt() returns.**** INVARIANTS:**** {F12271} The [sqlite3_interrupt()] interface will force all running**          SQL statements associated with the same database connection**          to halt after processing at most one additional row of**          data.**** {F12272} Any SQL statement that is interrupted by [sqlite3_interrupt()]**          will return [SQLITE_INTERRUPT].**** LIMITATIONS:**** {U12279} If the database connection closes while [sqlite3_interrupt()]**          is running then bad things will likely happen.*/void sqlite3_interrupt(sqlite3*);/*** CAPI3REF: Determine If An SQL Statement Is Complete {F10510}**** These routines are useful for command-line input to determine if the** currently entered text seems to form complete a SQL statement or** if additional input is needed before sending the text into** SQLite for parsing.  These routines return true if the input string** appears to be a complete SQL statement.  A statement is judged to be** complete if it ends with a semicolon token and is not a fragment of a** CREATE TRIGGER statement.  Semicolons that are embedded within** string literals or quoted identifier names or comments are not** independent tokens (they are part of the token in which they are** embedded) and thus do not count as a statement terminator.**** These routines do not parse the SQL and** so will not detect syntactically incorrect SQL.**** INVARIANTS:**** {F10511} The sqlite3_complete() and sqlite3_complete16() functions**          return true (non-zero) if and only if the last**          non-whitespace token in their input is a semicolon that**          is not in between the BEGIN and END of a CREATE TRIGGER**          statement.**** LIMITATIONS:**** {U10512} The input to sqlite3_complete() must be a zero-terminated**          UTF-8 string.**** {U10513} The input to sqlite3_complete16() must be a zero-terminated**          UTF-16 string in native byte order.*/int sqlite3_complete(const char *sql);int sqlite3_complete16(const void *sql);/*** CAPI3REF: Register A Callback To Handle SQLITE_BUSY Errors {F12310}**** This routine identifies a callback function that might be** invoked whenever an attempt is made to open a database table ** that another thread or process has locked.** If the busy callback is NULL, then [SQLITE_BUSY]** or [SQLITE_IOERR_BLOCKED]** is returned immediately upon encountering the lock.** If the busy callback is not NULL, then the** callback will be invoked with two arguments.  The** first argument to the handler is a copy of the void* pointer which** is the third argument to this routine.  The second argument to** the handler is the number of times that the busy handler has** been invoked for this locking event.   If the** busy callback returns 0, then no additional attempts are made to** access the database and [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED] is returned.** If the callback returns non-zero, then another attempt** is made to open the database for reading and the cycle repeats.**** The presence of a busy handler does not guarantee that** it will be invoked when there is lock contention.** If SQLite determines that invoking the busy handler could result in** a deadlock, it will go ahead and return [SQLITE_BUSY] or** [SQLITE_IOERR_BLOCKED] instead of invoking the** busy handler.** Consider a scenario where one process is holding a read lock that** it is trying to promote to a reserved lock and** a second process is holding a reserved lock that it is trying** to promote to an exclusive lock.  The first process cannot proceed** because it is blocked by the second and the second process cannot** proceed because it is blocked by the first.  If both processes** invoke the busy handlers, neither will make any progress.  Therefore,** SQLite returns [SQLITE_BUSY] for the first process, hoping that this** will induce the first process to release its read lock and allow** the second process to proceed.**** The default busy callback is NULL.**** The [SQLITE_BUSY] error is converted to [SQLITE_IOERR_BLOCKED]** when SQLite is in the middle of a large transaction where all the** changes will not fit into the in-memory cache.  SQLite will** already hold a RESERVED lock on the database file, but it needs** to promote this lock to EXCLUSIVE so that it can spill cache** pages into the database file without harm to concurrent** readers.  If it is unable to promote the lock, then the in-memory** cache will be left in an inconsistent state and so the error** code is promoted from the relatively benign [SQLITE_BUSY] to** the more severe [SQLITE_IOERR_BLOCKED].  This error code promotion** forces an automatic rollback of the changes.  See the** <a href="http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError">** CorruptionFollowingBusyError</a> wiki page for a discussion of why** this is important.**	** There can only be a single busy handler defined for each database** connection.  Setting a new busy handler clears any previous one. ** Note that calling [sqlite3_busy_timeout()] will also set or clear** the busy handler.**** INVARIANTS:**** {F12311} The [sqlite3_busy_handler()] function replaces the busy handler**          callback in the database connection identified by the 1st**          parameter with a new busy handler identified by the 2nd and 3rd**          parameters.**** {F12312} The default busy handler for new database connections is NULL.**** {F12314} When two or more database connection share a common cache,**          the busy handler for the database connection currently using**          the cache is invoked when the cache encounters a lock.**** {F12316} If a busy handler callback returns zero, then the SQLite**          interface that provoked the locking event will return**          [SQLITE_BUSY].**** {F12318} SQLite will invokes the busy handler with two argument which**          are a copy of the pointer supplied by the 3rd parameter to**          [sqlite3_busy_handler()] and a count of the number of prior**          invocations of the busy handler for the same locking event.**** LIMITATIONS:**** {U12319} A busy handler should not call close the database connection**          or prepared statement that invoked the busy handler.*/int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*);/*** CAPI3REF: Set A Busy Timeout {F12340}**** This routine sets a [sqlite3_busy_handler | busy handler]** that sleeps for a while when a** table is locked.  The handler will sleep multiple times until ** at least "ms" milliseconds of sleeping have been done. {F12343} After** "ms" milliseconds of sleeping, the handler returns 0 which** causes [sqlite3_step()] to return [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED].**** Calling this routine with an argument less than or equal to zero** turns off all busy handlers.**** There can only be a single busy handler for a particular database** connection.  If another busy handler was defined  ** (using [sqlite3_busy_handler()]) prior to calling** this routine, that other busy handler is cleared.**** INVARIANTS:**** {F12341} The [sqlite3_busy_timeout()] function overrides any prior**          [sqlite3_busy_timeout()] or [sqlite3_busy_handler()] setting**          on the same database connection.**** {F12343} If the 2nd parameter to [sqlite3_busy_timeout()] is less than**          or equal to zero, then the busy handler is cleared so that**          all subsequent locking events immediately return [SQLITE_BUSY].**** {F12344} If the 2nd parameter to [sqlite3_busy_timeout()] is a positive**          number N, then a busy handler is set that repeatedly calls**          the xSleep() method in the VFS interface until either the