| OLD | NEW | 
 | (Empty) | 
|     1 set rcsid {$Id: capi3ref.tcl,v 1.60 2007/05/19 06:48:43 danielk1977 Exp $} |  | 
|     2 source common.tcl |  | 
|     3 header {C/C++ Interface For SQLite Version 3} |  | 
|     4 puts { |  | 
|     5 <h2 class=pdf_section>C/C++ Interface For SQLite Version 3</h2> |  | 
|     6 } |  | 
|     7  |  | 
|     8 proc api {name prototype desc {notused x}} { |  | 
|     9   global apilist specialname |  | 
|    10   if {$name==""} { |  | 
|    11     regsub -all {sqlite3_[a-z0-9_]+\(} $prototype \ |  | 
|    12       {[lappend name [string trimright & (]]} x1 |  | 
|    13     subst $x1 |  | 
|    14   } else { |  | 
|    15     lappend specialname $name |  | 
|    16   } |  | 
|    17   lappend apilist [list $name $prototype $desc] |  | 
|    18 } |  | 
|    19  |  | 
|    20 api {extended-result-codes} { |  | 
|    21 #define SQLITE_IOERR_READ        |  | 
|    22 #define SQLITE_IOERR_SHORT_READ  |  | 
|    23 #define SQLITE_IOERR_WRITE       |  | 
|    24 #define SQLITE_IOERR_FSYNC       |  | 
|    25 #define SQLITE_IOERR_DIR_FSYNC   |  | 
|    26 #define SQLITE_IOERR_TRUNCATE    |  | 
|    27 #define SQLITE_IOERR_FSTAT       |  | 
|    28 #define SQLITE_IOERR_UNLOCK      |  | 
|    29 #define SQLITE_IOERR_RDLOCK      |  | 
|    30 ... |  | 
|    31 } { |  | 
|    32 In its default configuration, SQLite API routines return one of 26 integer |  | 
|    33 result codes described at result-codes.  However, experience has shown that |  | 
|    34 many of these result codes are too course-grained.  They do not provide as |  | 
|    35 much information about problems as users might like.  In an effort to |  | 
|    36 address this, newer versions of SQLite (version 3.3.8 and later) include |  | 
|    37 support for additional result codes that provide more detailed information |  | 
|    38 about errors.  The extended result codes are enabled (or disabled) for  |  | 
|    39 each database |  | 
|    40 connection using the sqlite3_extended_result_codes() API. |  | 
|    41  |  | 
|    42 Some of the available extended result codes are listed above. |  | 
|    43 We expect the number of extended result codes will be expand |  | 
|    44 over time.  Software that uses extended result codes should expect |  | 
|    45 to see new result codes in future releases of SQLite. |  | 
|    46  |  | 
|    47 The symbolic name for an extended result code always contains a related |  | 
|    48 primary result code as a prefix.  Primary result codes contain a single |  | 
|    49 "_" character.  Extended result codes contain two or more "_" characters. |  | 
|    50 The numeric value of an extended result code can be converted to its |  | 
|    51 corresponding primary result code by masking off the lower 8 bytes. |  | 
|    52  |  | 
|    53 A complete list of available extended result codes and |  | 
|    54 details about the meaning of the various extended result codes can be |  | 
|    55 found by consulting the C code, especially the sqlite3.h header |  | 
|    56 file and its antecedent sqlite.h.in.  Additional information |  | 
|    57 is also available at the SQLite wiki: |  | 
|    58 http://www.sqlite.org/cvstrac/wiki?p=ExtendedResultCodes |  | 
|    59 } |  | 
|    60  |  | 
|    61  |  | 
|    62 api {result-codes} { |  | 
|    63 #define SQLITE_OK           0   /* Successful result */ |  | 
|    64 #define SQLITE_ERROR        1   /* SQL error or missing database */ |  | 
|    65 #define SQLITE_INTERNAL     2   /* An internal logic error in SQLite */ |  | 
|    66 #define SQLITE_PERM         3   /* Access permission denied */ |  | 
|    67 #define SQLITE_ABORT        4   /* Callback routine requested an abort */ |  | 
|    68 #define SQLITE_BUSY         5   /* The database file is locked */ |  | 
|    69 #define SQLITE_LOCKED       6   /* A table in the database is locked */ |  | 
|    70 #define SQLITE_NOMEM        7   /* A malloc() failed */ |  | 
|    71 #define SQLITE_READONLY     8   /* Attempt to write a readonly database */ |  | 
|    72 #define SQLITE_INTERRUPT    9   /* Operation terminated by sqlite_interrupt() */ |  | 
|    73 #define SQLITE_IOERR       10   /* Some kind of disk I/O error occurred */ |  | 
|    74 #define SQLITE_CORRUPT     11   /* The database disk image is malformed */ |  | 
|    75 #define SQLITE_NOTFOUND    12   /* (Internal Only) Table or record not found */ |  | 
|    76 #define SQLITE_FULL        13   /* Insertion failed because database is full */ |  | 
|    77 #define SQLITE_CANTOPEN    14   /* Unable to open the database file */ |  | 
|    78 #define SQLITE_PROTOCOL    15   /* Database lock protocol error */ |  | 
|    79 #define SQLITE_EMPTY       16   /* (Internal Only) Database table is empty */ |  | 
|    80 #define SQLITE_SCHEMA      17   /* The database schema changed */ |  | 
|    81 #define SQLITE_TOOBIG      18   /* Too much data for one row of a table */ |  | 
|    82 #define SQLITE_CONSTRAINT  19   /* Abort due to constraint violation */ |  | 
|    83 #define SQLITE_MISMATCH    20   /* Data type mismatch */ |  | 
|    84 #define SQLITE_MISUSE      21   /* Library used incorrectly */ |  | 
|    85 #define SQLITE_NOLFS       22   /* Uses OS features not supported on host */ |  | 
|    86 #define SQLITE_AUTH        23   /* Authorization denied */ |  | 
|    87 #define SQLITE_ROW         100  /* sqlite_step() has another row ready */ |  | 
|    88 #define SQLITE_DONE        101  /* sqlite_step() has finished executing */ |  | 
|    89 } { |  | 
|    90 Many SQLite functions return an integer result code from the set shown |  | 
|    91 above in order to indicates success or failure. |  | 
|    92  |  | 
|    93 The result codes above are the only ones returned by SQLite in its |  | 
|    94 default configuration.  However, the sqlite3_extended_result_codes() |  | 
|    95 API can be used to set a database connectoin to return more detailed |  | 
|    96 result codes.  See the documentation on sqlite3_extended_result_codes() |  | 
|    97 or extended-result-codes for additional information. |  | 
|    98 } |  | 
|    99  |  | 
|   100 api {} { |  | 
|   101   int sqlite3_extended_result_codes(sqlite3*, int onoff); |  | 
|   102 } { |  | 
|   103 This routine enables or disabled extended-result-codes feature. |  | 
|   104 By default, SQLite API routines return one of only 26 integer |  | 
|   105 result codes described at result-codes.  When extended result codes |  | 
|   106 are enabled by this routine, the repetoire of result codes can be |  | 
|   107 much larger and can (hopefully) provide more detailed information |  | 
|   108 about the cause of an error. |  | 
|   109  |  | 
|   110 The second argument is a boolean value that turns extended result |  | 
|   111 codes on and off.  Extended result codes are off by default for |  | 
|   112 backwards compatibility with older versions of SQLite. |  | 
|   113 } |  | 
|   114  |  | 
|   115 api {} { |  | 
|   116   const char *sqlite3_libversion(void); |  | 
|   117 } { |  | 
|   118   Return a pointer to a string which contains the version number of |  | 
|   119   the library.  The same string is available in the global |  | 
|   120   variable named "sqlite3_version".  This interface is provided since |  | 
|   121   windows is unable to access global variables in DLLs. |  | 
|   122 } |  | 
|   123  |  | 
|   124 api {} { |  | 
|   125   void *sqlite3_aggregate_context(sqlite3_context*, int nBytes); |  | 
|   126 } { |  | 
|   127   Aggregate functions use this routine to allocate |  | 
|   128   a structure for storing their state.  The first time this routine |  | 
|   129   is called for a particular aggregate, a new structure of size nBytes |  | 
|   130   is allocated, zeroed, and returned.  On subsequent calls (for the |  | 
|   131   same aggregate instance) the same buffer is returned.  The implementation |  | 
|   132   of the aggregate can use the returned buffer to accumulate data. |  | 
|   133  |  | 
|   134   The buffer is freed automatically by SQLite when the query that |  | 
|   135   invoked the aggregate function terminates. |  | 
|   136 } |  | 
|   137  |  | 
|   138 api {} { |  | 
|   139   int sqlite3_aggregate_count(sqlite3_context*); |  | 
|   140 } { |  | 
|   141   This function is deprecated.   It continues to exist so as not to |  | 
|   142   break any legacy code that might happen to use it.  But it should not |  | 
|   143   be used in any new code. |  | 
|   144  |  | 
|   145   In order to encourage people to not use this function, we are not going |  | 
|   146   to tell you what it does. |  | 
|   147 } |  | 
|   148  |  | 
|   149 api {} { |  | 
|   150   int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*)); |  | 
|   151   int sqlite3_bind_double(sqlite3_stmt*, int, double); |  | 
|   152   int sqlite3_bind_int(sqlite3_stmt*, int, int); |  | 
|   153   int sqlite3_bind_int64(sqlite3_stmt*, int, long long int); |  | 
|   154   int sqlite3_bind_null(sqlite3_stmt*, int); |  | 
|   155   int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); |  | 
|   156   int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, void(*)(void*)
      ); |  | 
|   157   #define SQLITE_STATIC      ((void(*)(void *))0) |  | 
|   158   #define SQLITE_TRANSIENT   ((void(*)(void *))-1) |  | 
|   159 } { |  | 
|   160  In the SQL strings input to sqlite3_prepare_v2() and sqlite3_prepare16_v2(), |  | 
|   161  one or more literals can be replace by a parameter "?" or "?NNN" |  | 
|   162  or ":AAA" or "@AAA" or "\$VVV" where NNN is an integer literal, |  | 
|   163  AAA is an alphanumeric identifier and VVV is a variable name according |  | 
|   164  to the syntax rules of the TCL programming language. |  | 
|   165  The values of these parameters (also called "host parameter names") |  | 
|   166  can be set using the sqlite3_bind_*() routines. |  | 
|   167  |  | 
|   168  The first argument to the sqlite3_bind_*() routines always is a pointer |  | 
|   169  to the sqlite3_stmt structure returned from sqlite3_prepare_v2().  The second |  | 
|   170  argument is the index of the parameter to be set.  The first parameter has |  | 
|   171  an index of 1. When the same named parameter is used more than once, second |  | 
|   172  and subsequent |  | 
|   173  occurrences have the same index as the first occurrence.  The index for |  | 
|   174  named parameters can be looked up using the |  | 
|   175  sqlite3_bind_parameter_name() API if desired.  The index for "?NNN" |  | 
|   176  parametes is the value of NNN.  The NNN value must be between 1 and 999. |  | 
|   177  |  | 
|   178  |  | 
|   179  The third argument is the value to bind to the parameter. |  | 
|   180  |  | 
|   181  In those |  | 
|   182  routines that have a fourth argument, its value is the number of bytes |  | 
|   183  in the parameter.  To be clear: the value is the number of bytes in the |  | 
|   184  string, not the number of characters.  The number |  | 
|   185  of bytes does not include the zero-terminator at the end of strings. |  | 
|   186  If the fourth parameter is negative, the length of the string is |  | 
|   187  number of bytes up to the first zero terminator. |  | 
|   188  |  | 
|   189  The fifth argument to sqlite3_bind_blob(), sqlite3_bind_text(), and |  | 
|   190  sqlite3_bind_text16() is a destructor used to dispose of the BLOB or |  | 
|   191  text after SQLite has finished with it.  If the fifth argument is the |  | 
|   192  special value SQLITE_STATIC, then the library assumes that the information |  | 
|   193  is in static, unmanaged space and does not need to be freed.  If the |  | 
|   194  fifth argument has the value SQLITE_TRANSIENT, then SQLite makes its |  | 
|   195  own private copy of the data immediately, before the sqlite3_bind_*() |  | 
|   196  routine returns. |  | 
|   197  |  | 
|   198  The sqlite3_bind_*() routines must be called after |  | 
|   199  sqlite3_prepare_v2() or sqlite3_reset() and before sqlite3_step(). |  | 
|   200  Bindings are not cleared by the sqlite3_reset() routine. |  | 
|   201  Unbound parameters are interpreted as NULL. |  | 
|   202  |  | 
|   203  These routines return SQLITE_OK on success or an error code if |  | 
|   204  anything goes wrong.  SQLITE_RANGE is returned if the parameter |  | 
|   205  index is out of range.  SQLITE_NOMEM is returned if malloc fails. |  | 
|   206  SQLITE_MISUSE is returned if these routines are called on a virtual |  | 
|   207  machine that is the wrong state or which has already been finalized. |  | 
|   208 } |  | 
|   209  |  | 
|   210 api {} { |  | 
|   211   int sqlite3_bind_parameter_count(sqlite3_stmt*); |  | 
|   212 } { |  | 
|   213   Return the number of parameters in the precompiled statement given as |  | 
|   214   the argument. |  | 
|   215 } |  | 
|   216  |  | 
|   217 api {} { |  | 
|   218   const char *sqlite3_bind_parameter_name(sqlite3_stmt*, int n); |  | 
|   219 } { |  | 
|   220   Return the name of the n-th parameter in the precompiled statement. |  | 
|   221   Parameters of the form ":AAA" or "@AAA" or "\$VVV" have a name which is the |  | 
|   222   string ":AAA" or "@AAA" or "\$VVV".   |  | 
|   223   In other words, the initial ":" or "$" or "@" |  | 
|   224   is included as part of the name. |  | 
|   225   Parameters of the form "?" or "?NNN" have no name. |  | 
|   226  |  | 
|   227   The first bound parameter has an index of 1, not 0. |  | 
|   228  |  | 
|   229   If the value n is out of range or if the n-th parameter is nameless, |  | 
|   230   then NULL is returned.  The returned string is always in the |  | 
|   231   UTF-8 encoding even if the named parameter was originally specified |  | 
|   232   as UTF-16 in sqlite3_prepare16_v2(). |  | 
|   233 } |  | 
|   234  |  | 
|   235 api {} { |  | 
|   236   int sqlite3_bind_parameter_index(sqlite3_stmt*, const char *zName); |  | 
|   237 } { |  | 
|   238   Return the index of the parameter with the given name. |  | 
|   239   The name must match exactly. |  | 
|   240   If there is no parameter with the given name, return 0. |  | 
|   241   The string zName is always in the UTF-8 encoding. |  | 
|   242 } |  | 
|   243  |  | 
|   244 api {} { |  | 
|   245   int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*); |  | 
|   246 } { |  | 
|   247  This routine identifies a callback function that might be invoked |  | 
|   248  whenever an attempt is made to open a database table  |  | 
|   249  that another thread or process has locked. |  | 
|   250  If the busy callback is NULL, then SQLITE_BUSY is returned immediately |  | 
|   251  upon encountering the lock. |  | 
|   252  If the busy callback is not NULL, then the |  | 
|   253  callback will be invoked with two arguments.  The |  | 
|   254  first argument to the handler is a copy of the void* pointer which |  | 
|   255  is the third argument to this routine.  The second argument to |  | 
|   256  the handler is the number of times that the busy handler has |  | 
|   257  been invoked for this locking event. If the |  | 
|   258  busy callback returns 0, then no additional attempts are made to |  | 
|   259  access the database and SQLITE_BUSY is returned. |  | 
|   260  If the callback returns non-zero, then another attempt is made to open the |  | 
|   261  database for reading and the cycle repeats. |  | 
|   262  |  | 
|   263  The presence of a busy handler does not guarantee that |  | 
|   264  it will be invoked when there is lock contention. |  | 
|   265  If SQLite determines that invoking the busy handler could result in |  | 
|   266  a deadlock, it will return SQLITE_BUSY instead. |  | 
|   267  Consider a scenario where one process is holding a read lock that |  | 
|   268  it is trying to promote to a reserved lock and |  | 
|   269  a second process is holding a reserved lock that it is trying |  | 
|   270  to promote to an exclusive lock.  The first process cannot proceed |  | 
|   271  because it is blocked by the second and the second process cannot |  | 
|   272  proceed because it is blocked by the first.  If both processes |  | 
|   273  invoke the busy handlers, neither will make any progress.  Therefore, |  | 
|   274  SQLite returns SQLITE_BUSY for the first process, hoping that this |  | 
|   275  will induce the first process to release its read lock and allow |  | 
|   276  the second process to proceed. |  | 
|   277  |  | 
|   278  The default busy callback is NULL. |  | 
|   279  |  | 
|   280  Sqlite is re-entrant, so the busy handler may start a new query.  |  | 
|   281  (It is not clear why anyone would every want to do this, but it |  | 
|   282  is allowed, in theory.)  But the busy handler may not close the |  | 
|   283  database.  Closing the database from a busy handler will delete  |  | 
|   284  data structures out from under the executing query and will  |  | 
|   285  probably result in a coredump. |  | 
|   286  |  | 
|   287  There can only be a single busy handler defined for each database |  | 
|   288  connection.  Setting a new busy handler clears any previous one. |  | 
|   289  Note that calling sqlite3_busy_timeout() will also set or clear |  | 
|   290  the busy handler. |  | 
|   291 } |  | 
|   292  |  | 
|   293 api {} { |  | 
|   294   int sqlite3_busy_timeout(sqlite3*, int ms); |  | 
|   295 } { |  | 
|   296  This routine sets a busy handler that sleeps for a while when a |  | 
|   297  table is locked.  The handler will sleep multiple times until  |  | 
|   298  at least "ms" milliseconds of sleeping have been done.  After |  | 
|   299  "ms" milliseconds of sleeping, the handler returns 0 which |  | 
|   300  causes sqlite3_exec() to return SQLITE_BUSY. |  | 
|   301  |  | 
|   302  Calling this routine with an argument less than or equal to zero |  | 
|   303  turns off all busy handlers. |  | 
|   304  |  | 
|   305  There can only be a single busy handler for a particular database |  | 
|   306  connection.  If another busy handler was defined   |  | 
|   307  (using sqlite3_busy_handler()) prior to calling |  | 
|   308  this routine, that other busy handler is cleared. |  | 
|   309 } |  | 
|   310  |  | 
|   311 api {} { |  | 
|   312   int sqlite3_changes(sqlite3*); |  | 
|   313 } { |  | 
|   314  This function returns the number of database rows that were changed |  | 
|   315  (or inserted or deleted) by the most recently completed |  | 
|   316  INSERT, UPDATE, or DELETE |  | 
|   317  statement.  Only changes that are directly specified by the INSERT, |  | 
|   318  UPDATE, or DELETE statement are counted.  Auxiliary changes caused by |  | 
|   319  triggers are not counted.  Use the sqlite3_total_changes() function |  | 
|   320  to find the total number of changes including changes caused by triggers. |  | 
|   321  |  | 
|   322  Within the body of a trigger, the sqlite3_changes() function does work |  | 
|   323  to report the number of rows that were changed for the most recently |  | 
|   324  completed INSERT, UPDATE, or DELETE statement within the trigger body. |  | 
|   325  |  | 
|   326  SQLite implements the command "DELETE FROM table" without a WHERE clause |  | 
|   327  by dropping and recreating the table.  (This is much faster than going |  | 
|   328  through and deleting individual elements from the table.)  Because of |  | 
|   329  this optimization, the change count for "DELETE FROM table" will be |  | 
|   330  zero regardless of the number of elements that were originally in the |  | 
|   331  table. To get an accurate count of the number of rows deleted, use |  | 
|   332  "DELETE FROM table WHERE 1" instead. |  | 
|   333 } |  | 
|   334  |  | 
|   335 api {} { |  | 
|   336   int sqlite3_total_changes(sqlite3*); |  | 
|   337 } { |  | 
|   338   This function returns the total number of database rows that have |  | 
|   339   be modified, inserted, or deleted since the database connection was |  | 
|   340   created using sqlite3_open().  All changes are counted, including |  | 
|   341   changes by triggers and changes to TEMP and auxiliary databases. |  | 
|   342   Except, changes to the SQLITE_MASTER table (caused by statements  |  | 
|   343   such as CREATE TABLE) are not counted.  Nor are changes counted when |  | 
|   344   an entire table is deleted using DROP TABLE. |  | 
|   345  |  | 
|   346   See also the sqlite3_changes() API. |  | 
|   347  |  | 
|   348   SQLite implements the command "DELETE FROM table" without a WHERE clause |  | 
|   349   by dropping and recreating the table.  (This is much faster than going |  | 
|   350   through and deleting individual elements form the table.)  Because of |  | 
|   351   this optimization, the change count for "DELETE FROM table" will be |  | 
|   352   zero regardless of the number of elements that were originally in the |  | 
|   353   table. To get an accurate count of the number of rows deleted, use |  | 
|   354   "DELETE FROM table WHERE 1" instead. |  | 
|   355 } |  | 
|   356  |  | 
|   357 api {} { |  | 
|   358   int sqlite3_close(sqlite3*); |  | 
|   359 } { |  | 
|   360   Call this function with a pointer to a structure that was previously |  | 
|   361   returned from sqlite3_open() or sqlite3_open16() |  | 
|   362   and the corresponding database will by closed. |  | 
|   363  |  | 
|   364   SQLITE_OK is returned if the close is successful.  If there are |  | 
|   365   prepared statements that have not been finalized, then SQLITE_BUSY |  | 
|   366   is returned.  SQLITE_ERROR might be returned if the argument is not |  | 
|   367   a valid connection pointer returned by sqlite3_open() or if the connection |  | 
|   368   pointer has been closed previously. |  | 
|   369 } |  | 
|   370  |  | 
|   371 api {} { |  | 
|   372 const void *sqlite3_column_blob(sqlite3_stmt*, int iCol); |  | 
|   373 int sqlite3_column_bytes(sqlite3_stmt*, int iCol); |  | 
|   374 int sqlite3_column_bytes16(sqlite3_stmt*, int iCol); |  | 
|   375 double sqlite3_column_double(sqlite3_stmt*, int iCol); |  | 
|   376 int sqlite3_column_int(sqlite3_stmt*, int iCol); |  | 
|   377 long long int sqlite3_column_int64(sqlite3_stmt*, int iCol); |  | 
|   378 const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol); |  | 
|   379 const void *sqlite3_column_text16(sqlite3_stmt*, int iCol); |  | 
|   380 int sqlite3_column_type(sqlite3_stmt*, int iCol); |  | 
|   381 #define SQLITE_INTEGER  1 |  | 
|   382 #define SQLITE_FLOAT    2 |  | 
|   383 #define SQLITE_TEXT     3 |  | 
|   384 #define SQLITE_BLOB     4 |  | 
|   385 #define SQLITE_NULL     5 |  | 
|   386 } { |  | 
|   387  These routines return information about the information |  | 
|   388  in a single column of the current result row of a query.  In every |  | 
|   389  case the first argument is a pointer to the SQL statement that is being |  | 
|   390  executed (the sqlite_stmt* that was returned from sqlite3_prepare_v2()) and |  | 
|   391  the second argument is the index of the column for which information  |  | 
|   392  should be returned.  iCol is zero-indexed.  The left-most column has an |  | 
|   393  index of 0. |  | 
|   394  |  | 
|   395  If the SQL statement is not currently point to a valid row, or if the |  | 
|   396  the column index is out of range, the result is undefined. |  | 
|   397  |  | 
|   398  The sqlite3_column_type() routine returns the initial data type |  | 
|   399  of the result column.  The returned value is one of SQLITE_INTEGER, |  | 
|   400  SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB, or SQLITE_NULL.  The value |  | 
|   401  returned by sqlite3_column_type() is only meaningful if no type |  | 
|   402  conversions have occurred as described below.  After a type conversion, |  | 
|   403  the value returned by sqlite3_column_type() is undefined.  Future |  | 
|   404  versions of SQLite may change the behavior of sqlite3_column_type() |  | 
|   405  following a type conversion. |  | 
|   406  |  | 
|   407  If the result is a BLOB or UTF-8 string then the sqlite3_column_bytes()  |  | 
|   408  routine returns the number of bytes in that BLOB or string. |  | 
|   409  If the result is a UTF-16 string, then sqlite3_column_bytes() converts |  | 
|   410  the string to UTF-8 and then returns the number of bytes. |  | 
|   411  If the result is a numeric value then sqlite3_column_bytes() uses |  | 
|   412  sqlite3_snprintf() to convert that value to a UTF-8 string and returns |  | 
|   413  the number of bytes in that string. |  | 
|   414  The value returned does |  | 
|   415  not include the \\000 terminator at the end of the string.   |  | 
|   416  |  | 
|   417  The sqlite3_column_bytes16() routine is similar to sqlite3_column_bytes() |  | 
|   418  but leaves the result in UTF-16 instead of UTF-8.   |  | 
|   419  The \\u0000 terminator is not included in this count. |  | 
|   420  |  | 
|   421  These routines attempt to convert the value where appropriate.  For |  | 
|   422  example, if the internal representation is FLOAT and a text result |  | 
|   423  is requested, sqlite3_snprintf() is used internally to do the conversion |  | 
|   424  automatically.  The following table details the conversions that |  | 
|   425  are applied: |  | 
|   426  |  | 
|   427 <blockquote> |  | 
|   428 <table border="1"> |  | 
|   429 <tr><th>Internal Type</th><th>Requested Type</th><th>Conversion</th></tr> |  | 
|   430 <tr><td> NULL    </td><td> INTEGER</td><td>Result is 0</td></tr> |  | 
|   431 <tr><td> NULL </td><td>    FLOAT </td><td> Result is 0.0</td></tr> |  | 
|   432 <tr><td> NULL </td><td>    TEXT </td><td>  Result is NULL pointer</td></tr> |  | 
|   433 <tr><td> NULL </td><td>    BLOB </td><td>  Result is NULL pointer</td></tr> |  | 
|   434 <tr><td> INTEGER </td><td> FLOAT </td><td> Convert from integer to float</td></t
      r> |  | 
|   435 <tr><td> INTEGER </td><td> TEXT </td><td>  ASCII rendering of the integer</td></
      tr> |  | 
|   436 <tr><td> INTEGER </td><td> BLOB </td><td>  Same as for INTEGER->TEXT</td></tr> |  | 
|   437 <tr><td> FLOAT </td><td>   INTEGER</td><td>Convert from float to integer</td></t
      r> |  | 
|   438 <tr><td> FLOAT </td><td>   TEXT </td><td>  ASCII rendering of the float</td></tr
      > |  | 
|   439 <tr><td> FLOAT </td><td>   BLOB </td><td>  Same as FLOAT->TEXT</td></tr> |  | 
|   440 <tr><td> TEXT </td><td>    INTEGER</td><td>Use atoi()</td></tr> |  | 
|   441 <tr><td> TEXT </td><td>    FLOAT </td><td> Use atof()</td></tr> |  | 
|   442 <tr><td> TEXT </td><td>    BLOB </td><td>  No change</td></tr> |  | 
|   443 <tr><td> BLOB </td><td>    INTEGER</td><td>Convert to TEXT then use atoi()</td><
      /tr> |  | 
|   444 <tr><td> BLOB </td><td>    FLOAT </td><td> Convert to TEXT then use atof()</td><
      /tr> |  | 
|   445 <tr><td> BLOB </td><td>    TEXT </td><td>  Add a \\000 terminator if needed</td>
      </tr> |  | 
|   446 </table> |  | 
|   447 </blockquote> |  | 
|   448  |  | 
|   449   Note that when type conversions occur, pointers returned by prior |  | 
|   450   calls to sqlite3_column_blob(), sqlite3_column_text(), and/or |  | 
|   451   sqlite3_column_text16() may be invalidated.  |  | 
|   452   Type conversions and pointer invalidations might occur |  | 
|   453   in the following cases: |  | 
|   454  |  | 
|   455   <ul> |  | 
|   456   <li><p> |  | 
|   457   The initial content is a BLOB and sqlite3_column_text()  |  | 
|   458   or sqlite3_column_text16() |  | 
|   459   is called.  A zero-terminator might need to be added to the string. |  | 
|   460   </p></li> |  | 
|   461   <li><p> |  | 
|   462   The initial content is UTF-8 text and sqlite3_column_bytes16() or |  | 
|   463   sqlite3_column_text16() is called.  The content must be converted to UTF-16. |  | 
|   464   </p></li> |  | 
|   465   <li><p> |  | 
|   466   The initial content is UTF-16 text and sqlite3_column_bytes() or |  | 
|   467   sqlite3_column_text() is called.  The content must be converted to UTF-8. |  | 
|   468   </p></li> |  | 
|   469   </ul> |  | 
|   470  |  | 
|   471   Conversions between UTF-16be and UTF-16le  |  | 
|   472   are always done in place and do |  | 
|   473   not invalidate a prior pointer, though of course the content of the buffer |  | 
|   474   that the prior pointer points to will have been modified.  Other kinds |  | 
|   475   of conversion are done in place when it is possible, but sometime it is |  | 
|   476   not possible and in those cases prior pointers are invalidated.   |  | 
|   477  |  | 
|   478   The safest and easiest to remember policy is to invoke these routines |  | 
|   479   in one of the following ways: |  | 
|   480  |  | 
|   481   <ul> |  | 
|   482   <li>sqlite3_column_text() followed by sqlite3_column_bytes()</li> |  | 
|   483   <li>sqlite3_column_blob() followed by sqlite3_column_bytes()</li> |  | 
|   484   <li>sqlite3_column_text16() followed by sqlite3_column_bytes16()</li> |  | 
|   485   </ul> |  | 
|   486  |  | 
|   487   In other words, you should call sqlite3_column_text(), sqlite3_column_blob(), |  | 
|   488   or sqlite3_column_text16() first to force the result into the desired |  | 
|   489   format, then invoke sqlite3_column_bytes() or sqlite3_column_bytes16() to |  | 
|   490   find the size of the result.  Do not mix call to sqlite3_column_text() or |  | 
|   491   sqlite3_column_blob() with calls to sqlite3_column_bytes16().  And do not |  | 
|   492   mix calls to sqlite3_column_text16() with calls to sqlite3_column_bytes(). |  | 
|   493 } |  | 
|   494  |  | 
|   495 api {} { |  | 
|   496 int sqlite3_column_count(sqlite3_stmt *pStmt); |  | 
|   497 } { |  | 
|   498  Return the number of columns in the result set returned by the prepared |  | 
|   499  SQL statement. This routine returns 0 if pStmt is an SQL statement |  | 
|   500  that does not return data (for example an UPDATE). |  | 
|   501  |  | 
|   502  See also sqlite3_data_count(). |  | 
|   503 } |  | 
|   504  |  | 
|   505 api {} { |  | 
|   506 const char *sqlite3_column_decltype(sqlite3_stmt *, int i); |  | 
|   507 const void *sqlite3_column_decltype16(sqlite3_stmt*,int); |  | 
|   508 } { |  | 
|   509  The first argument is a prepared SQL statement. If this statement |  | 
|   510  is a SELECT statement, the Nth column of the returned result set  |  | 
|   511  of the SELECT is a table column then the declared type of the table |  | 
|   512  column is returned. If the Nth column of the result set is not a table |  | 
|   513  column, then a NULL pointer is returned. The returned string is  |  | 
|   514  UTF-8 encoded for sqlite3_column_decltype() and UTF-16 encoded |  | 
|   515  for sqlite3_column_decltype16(). For example, in the database schema: |  | 
|   516  |  | 
|   517  <blockquote><pre> |  | 
|   518  CREATE TABLE t1(c1 INTEGER); |  | 
|   519  </pre></blockquote> |  | 
|   520  |  | 
|   521  And the following statement compiled: |  | 
|   522  |  | 
|   523  <blockquote><pre> |  | 
|   524  SELECT c1 + 1, c1 FROM t1; |  | 
|   525  </pre></blockquote> |  | 
|   526  |  | 
|   527  Then this routine would return the string "INTEGER" for the second |  | 
|   528  result column (i==1), and a NULL pointer for the first result column |  | 
|   529  (i==0). |  | 
|   530  |  | 
|   531  If the following statements were compiled then this routine would |  | 
|   532  return "INTEGER" for the first (only) result column. |  | 
|   533  |  | 
|   534  <blockquote><pre> |  | 
|   535  SELECT (SELECT c1) FROM t1; |  | 
|   536  SELECT (SELECT c1 FROM t1); |  | 
|   537  SELECT c1 FROM (SELECT c1 FROM t1); |  | 
|   538  SELECT * FROM (SELECT c1 FROM t1); |  | 
|   539  SELECT * FROM (SELECT * FROM t1); |  | 
|   540  </pre></blockquote> |  | 
|   541 } |  | 
|   542  |  | 
|   543 api {} { |  | 
|   544   int sqlite3_table_column_metadata( |  | 
|   545     sqlite3 *db,                /* Connection handle */ |  | 
|   546     const char *zDbName,        /* Database name or NULL */ |  | 
|   547     const char *zTableName,     /* Table name */ |  | 
|   548     const char *zColumnName,    /* Column name */ |  | 
|   549     char const **pzDataType,    /* OUTPUT: Declared data type */ |  | 
|   550     char const **pzCollSeq,     /* OUTPUT: Collation sequence name */ |  | 
|   551     int *pNotNull,              /* OUTPUT: True if NOT NULL constraint exists */ |  | 
|   552     int *pPrimaryKey,           /* OUTPUT: True if column part of PK */ |  | 
|   553     int *pAutoinc               /* OUTPUT: True if colums is auto-increment */ |  | 
|   554   ); |  | 
|   555 } { |  | 
|   556  This routine is used to obtain meta information about a specific column of a |  | 
|   557  specific database table accessible using the connection handle passed as the |  | 
|   558  first function argument. |  | 
|   559  |  | 
|   560  The column is identified by the second, third and fourth parameters to  |  | 
|   561  this function. The second parameter is either the name of the database |  | 
|   562  (i.e. "main", "temp" or an attached database) containing the specified |  | 
|   563  table or NULL. If it is NULL, then all attached databases are searched |  | 
|   564  for the table using the same algorithm as the database engine uses to  |  | 
|   565  resolve unqualified table references. |  | 
|   566  |  | 
|   567  The third and fourth parameters to this function are the table and column  |  | 
|   568  name of the desired column, respectively. Neither of these parameters  |  | 
|   569  may be NULL. |  | 
|   570  |  | 
|   571  Meta information is returned by writing to the memory locations passed as |  | 
|   572  the 5th and subsequent parameters to this function. Any of these  |  | 
|   573  arguments may be NULL, in which case the corresponding element of meta  |  | 
|   574  information is ommitted. |  | 
|   575  |  | 
|   576 <pre> |  | 
|   577  Parameter     Output Type      Description |  | 
|   578  ----------------------------------- |  | 
|   579    5th         const char*      Declared data type  |  | 
|   580    6th         const char*      Name of the columns default collation sequence  |  | 
|   581    7th         int              True if the column has a NOT NULL constraint |  | 
|   582    8th         int              True if the column is part of the PRIMARY KEY |  | 
|   583    9th         int              True if the column is AUTOINCREMENT |  | 
|   584 </pre> |  | 
|   585  |  | 
|   586  The memory pointed to by the character pointers returned for the  |  | 
|   587  declaration type and collation sequence is valid only until the next  |  | 
|   588  call to any sqlite API function. |  | 
|   589  |  | 
|   590  This function may load one or more schemas from database files. If an |  | 
|   591  error occurs during this process, or if the requested table or column |  | 
|   592  cannot be found, an SQLITE error code is returned and an error message |  | 
|   593  left in the database handle (to be retrieved using sqlite3_errmsg()). |  | 
|   594  Specifying an SQL view instead of a table as the third argument is also |  | 
|   595  considered an error. |  | 
|   596  |  | 
|   597  If the specified column is "rowid", "oid" or "_rowid_" and an  |  | 
|   598  INTEGER PRIMARY KEY column has been explicitly declared, then the output  |  | 
|   599  parameters are set for the explicitly declared column. If there is no |  | 
|   600  explicitly declared IPK column, then the data-type is "INTEGER", the |  | 
|   601  collation sequence "BINARY" and the primary-key flag is set. Both |  | 
|   602  the not-null and auto-increment flags are clear. |  | 
|   603  |  | 
|   604  This API is only available if the library was compiled with the |  | 
|   605  SQLITE_ENABLE_COLUMN_METADATA preprocessor symbol defined. |  | 
|   606 } |  | 
|   607  |  | 
|   608 api {} { |  | 
|   609 const char *sqlite3_column_database_name(sqlite3_stmt *pStmt, int N); |  | 
|   610 const void *sqlite3_column_database_name16(sqlite3_stmt *pStmt, int N); |  | 
|   611 } { |  | 
|   612 If the Nth column returned by statement pStmt is a column reference, |  | 
|   613 these functions may be used to access the name of the database (either  |  | 
|   614 "main", "temp" or the name of an attached database) that contains |  | 
|   615 the column. If the Nth column is not a column reference, NULL is |  | 
|   616 returned. |  | 
|   617  |  | 
|   618 See the description of function sqlite3_column_decltype() for a |  | 
|   619 description of exactly which expressions are considered column references. |  | 
|   620  |  | 
|   621 Function sqlite3_column_database_name() returns a pointer to a UTF-8 |  | 
|   622 encoded string. sqlite3_column_database_name16() returns a pointer |  | 
|   623 to a UTF-16 encoded string.  |  | 
|   624 } |  | 
|   625  |  | 
|   626 api {} { |  | 
|   627 const char *sqlite3_column_origin_name(sqlite3_stmt *pStmt, int N); |  | 
|   628 const void *sqlite3_column_origin_name16(sqlite3_stmt *pStmt, int N); |  | 
|   629 } { |  | 
|   630 If the Nth column returned by statement pStmt is a column reference, |  | 
|   631 these functions may be used to access the schema name of the referenced  |  | 
|   632 column in the database schema. If the Nth column is not a column  |  | 
|   633 reference, NULL is returned. |  | 
|   634  |  | 
|   635 See the description of function sqlite3_column_decltype() for a |  | 
|   636 description of exactly which expressions are considered column references. |  | 
|   637  |  | 
|   638 Function sqlite3_column_origin_name() returns a pointer to a UTF-8 |  | 
|   639 encoded string. sqlite3_column_origin_name16() returns a pointer |  | 
|   640 to a UTF-16 encoded string.  |  | 
|   641 } |  | 
|   642  |  | 
|   643 api {} { |  | 
|   644 const char *sqlite3_column_table_name(sqlite3_stmt *pStmt, int N); |  | 
|   645 const void *sqlite3_column_table_name16(sqlite3_stmt *pStmt, int N); |  | 
|   646 } { |  | 
|   647 If the Nth column returned by statement pStmt is a column reference,  |  | 
|   648 these functions may be used to access the name of the table that  |  | 
|   649 contains the column.  If the Nth column is not a column reference,  |  | 
|   650 NULL is returned. |  | 
|   651  |  | 
|   652 See the description of function sqlite3_column_decltype() for a |  | 
|   653 description of exactly which expressions are considered column references. |  | 
|   654  |  | 
|   655 Function sqlite3_column_table_name() returns a pointer to a UTF-8 |  | 
|   656 encoded string. sqlite3_column_table_name16() returns a pointer |  | 
|   657 to a UTF-16 encoded string.  |  | 
|   658 } |  | 
|   659  |  | 
|   660 api {} { |  | 
|   661 const char *sqlite3_column_name(sqlite3_stmt*,int); |  | 
|   662 const void *sqlite3_column_name16(sqlite3_stmt*,int); |  | 
|   663 } { |  | 
|   664  The first argument is a prepared SQL statement. This function returns |  | 
|   665  the column heading for the Nth column of that statement, where N is the |  | 
|   666  second function argument.  The string returned is UTF-8 for |  | 
|   667  sqlite3_column_name() and UTF-16 for sqlite3_column_name16(). |  | 
|   668 } |  | 
|   669  |  | 
|   670 api {} { |  | 
|   671 void *sqlite3_commit_hook(sqlite3*, int(*xCallback)(void*), void *pArg); |  | 
|   672 } { |  | 
|   673  <i>Experimental</i> |  | 
|   674  |  | 
|   675  Register a callback function to be invoked whenever a new transaction |  | 
|   676  is committed.  The pArg argument is passed through to the callback. |  | 
|   677  callback.  If the callback function returns non-zero, then the commit |  | 
|   678  is converted into a rollback. |  | 
|   679  |  | 
|   680  If another function was previously registered, its pArg value is returned. |  | 
|   681  Otherwise NULL is returned. |  | 
|   682  |  | 
|   683  Registering a NULL function disables the callback.  Only a single commit |  | 
|   684  hook callback can be registered at a time. |  | 
|   685 } |  | 
|   686  |  | 
|   687 api {} { |  | 
|   688 int sqlite3_complete(const char *sql); |  | 
|   689 int sqlite3_complete16(const void *sql); |  | 
|   690 } { |  | 
|   691  These functions return true if the given input string comprises |  | 
|   692  one or more complete SQL statements. |  | 
|   693  The argument must be a nul-terminated UTF-8 string for sqlite3_complete() |  | 
|   694  and a nul-terminated UTF-16 string for sqlite3_complete16(). |  | 
|   695  |  | 
|   696  These routines do not check to see if the SQL statement is well-formed. |  | 
|   697  They only check to see that the statement is terminated by a semicolon |  | 
|   698  that is not part of a string literal and is not inside |  | 
|   699  the body of a trigger. |  | 
|   700 } {} |  | 
|   701  |  | 
|   702 api {} { |  | 
|   703 int sqlite3_create_collation( |  | 
|   704   sqlite3*,  |  | 
|   705   const char *zName,  |  | 
|   706   int pref16,  |  | 
|   707   void*, |  | 
|   708   int(*xCompare)(void*,int,const void*,int,const void*) |  | 
|   709 ); |  | 
|   710 int sqlite3_create_collation16( |  | 
|   711   sqlite3*,  |  | 
|   712   const char *zName,  |  | 
|   713   int pref16,  |  | 
|   714   void*, |  | 
|   715   int(*xCompare)(void*,int,const void*,int,const void*) |  | 
|   716 ); |  | 
|   717 #define SQLITE_UTF8     1 |  | 
|   718 #define SQLITE_UTF16BE  2 |  | 
|   719 #define SQLITE_UTF16LE  3 |  | 
|   720 #define SQLITE_UTF16    4 |  | 
|   721 } { |  | 
|   722  These two functions are used to add new collation sequences to the |  | 
|   723  sqlite3 handle specified as the first argument.  |  | 
|   724  |  | 
|   725  The name of the new collation sequence is specified as a UTF-8 string |  | 
|   726  for sqlite3_create_collation() and a UTF-16 string for |  | 
|   727  sqlite3_create_collation16(). In both cases the name is passed as the |  | 
|   728  second function argument. |  | 
|   729  |  | 
|   730  The third argument must be one of the constants SQLITE_UTF8, |  | 
|   731  SQLITE_UTF16LE or SQLITE_UTF16BE, indicating that the user-supplied |  | 
|   732  routine expects to be passed pointers to strings encoded using UTF-8, |  | 
|   733  UTF-16 little-endian or UTF-16 big-endian respectively.  The |  | 
|   734  SQLITE_UTF16 constant indicates that text strings are expected in |  | 
|   735  UTF-16 in the native byte order of the host machine. |  | 
|   736  |  | 
|   737  A pointer to the user supplied routine must be passed as the fifth |  | 
|   738  argument. If it is NULL, this is the same as deleting the collation |  | 
|   739  sequence (so that SQLite cannot call it anymore). Each time the user |  | 
|   740  supplied function is invoked, it is passed a copy of the void* passed as |  | 
|   741  the fourth argument to sqlite3_create_collation() or |  | 
|   742  sqlite3_create_collation16() as its first argument. |  | 
|   743  |  | 
|   744  The remaining arguments to the user-supplied routine are two strings, |  | 
|   745  each represented by a [length, data] pair and encoded in the encoding |  | 
|   746  that was passed as the third argument when the collation sequence was |  | 
|   747  registered. The user routine should return negative, zero or positive if |  | 
|   748  the first string is less than, equal to, or greater than the second |  | 
|   749  string. i.e. (STRING1 - STRING2). |  | 
|   750 } |  | 
|   751  |  | 
|   752 api {} { |  | 
|   753 int sqlite3_collation_needed( |  | 
|   754   sqlite3*,  |  | 
|   755   void*,  |  | 
|   756   void(*)(void*,sqlite3*,int eTextRep,const char*) |  | 
|   757 ); |  | 
|   758 int sqlite3_collation_needed16( |  | 
|   759   sqlite3*,  |  | 
|   760   void*, |  | 
|   761   void(*)(void*,sqlite3*,int eTextRep,const void*) |  | 
|   762 ); |  | 
|   763 } { |  | 
|   764  To avoid having to register all collation sequences before a database |  | 
|   765  can be used, a single callback function may be registered with the |  | 
|   766  database handle to be called whenever an undefined collation sequence is |  | 
|   767  required. |  | 
|   768  |  | 
|   769  If the function is registered using the sqlite3_collation_needed() API, |  | 
|   770  then it is passed the names of undefined collation sequences as strings |  | 
|   771  encoded in UTF-8. If sqlite3_collation_needed16() is used, the names |  | 
|   772  are passed as UTF-16 in machine native byte order. A call to either |  | 
|   773  function replaces any existing callback. |  | 
|   774  |  | 
|   775  When the user-function is invoked, the first argument passed is a copy |  | 
|   776  of the second argument to sqlite3_collation_needed() or |  | 
|   777  sqlite3_collation_needed16(). The second argument is the database |  | 
|   778  handle. The third argument is one of SQLITE_UTF8, SQLITE_UTF16BE or |  | 
|   779  SQLITE_UTF16LE, indicating the most desirable form of the collation |  | 
|   780  sequence function required. The fourth argument is the name of the |  | 
|   781  required collation sequence. |  | 
|   782  |  | 
|   783  The collation sequence is returned to SQLite by a collation-needed |  | 
|   784  callback using the sqlite3_create_collation() or |  | 
|   785  sqlite3_create_collation16() APIs, described above. |  | 
|   786 } |  | 
|   787  |  | 
|   788 api {} { |  | 
|   789 int sqlite3_create_function( |  | 
|   790   sqlite3 *, |  | 
|   791   const char *zFunctionName, |  | 
|   792   int nArg, |  | 
|   793   int eTextRep, |  | 
|   794   void *pUserData, |  | 
|   795   void (*xFunc)(sqlite3_context*,int,sqlite3_value**), |  | 
|   796   void (*xStep)(sqlite3_context*,int,sqlite3_value**), |  | 
|   797   void (*xFinal)(sqlite3_context*) |  | 
|   798 ); |  | 
|   799 int sqlite3_create_function16( |  | 
|   800   sqlite3*, |  | 
|   801   const void *zFunctionName, |  | 
|   802   int nArg, |  | 
|   803   int eTextRep, |  | 
|   804   void *pUserData, |  | 
|   805   void (*xFunc)(sqlite3_context*,int,sqlite3_value**), |  | 
|   806   void (*xStep)(sqlite3_context*,int,sqlite3_value**), |  | 
|   807   void (*xFinal)(sqlite3_context*) |  | 
|   808 ); |  | 
|   809 #define SQLITE_UTF8     1 |  | 
|   810 #define SQLITE_UTF16    2 |  | 
|   811 #define SQLITE_UTF16BE  3 |  | 
|   812 #define SQLITE_UTF16LE  4 |  | 
|   813 #define SQLITE_ANY      5 |  | 
|   814 } { |  | 
|   815  These two functions are used to add SQL functions or aggregates |  | 
|   816  implemented in C. The |  | 
|   817  only difference between these two routines is that the second argument, the |  | 
|   818  name of the (scalar) function or aggregate, is encoded in UTF-8 for |  | 
|   819  sqlite3_create_function() and UTF-16 for sqlite3_create_function16(). |  | 
|   820  The length of the name is limited to 255 bytes, exclusive of the  |  | 
|   821  zero-terminator.  Note that the name length limit is in bytes, not |  | 
|   822  characters.  Any attempt to create a function with a longer name |  | 
|   823  will result in an SQLITE_ERROR error. |  | 
|   824   |  | 
|   825  The first argument is the database handle that the new function or |  | 
|   826  aggregate is to be added to. If a single program uses more than one |  | 
|   827  database handle internally, then user functions or aggregates must  |  | 
|   828  be added individually to each database handle with which they will be |  | 
|   829  used. |  | 
|   830  |  | 
|   831  The third argument is the number of arguments that the function or |  | 
|   832  aggregate takes. If this argument is -1 then the function or |  | 
|   833  aggregate may take any number of arguments.  The maximum number |  | 
|   834  of arguments to a new SQL function is 127.  A number larger than |  | 
|   835  127 for the third argument results in an SQLITE_ERROR error. |  | 
|   836  |  | 
|   837  The fourth argument, eTextRep, specifies what type of text arguments |  | 
|   838  this function prefers to receive.  Any function should be able to work |  | 
|   839  work with UTF-8, UTF-16le, or UTF-16be.  But some implementations may be |  | 
|   840  more efficient with one representation than another.  Users are allowed |  | 
|   841  to specify separate implementations for the same function which are called |  | 
|   842  depending on the text representation of the arguments.  The the implementation |  | 
|   843  which provides the best match is used.  If there is only a single |  | 
|   844  implementation which does not care what text representation is used, |  | 
|   845  then the fourth argument should be SQLITE_ANY. |  | 
|   846  |  | 
|   847  The fifth argument is an arbitrary pointer.  The function implementations |  | 
|   848  can gain access to this pointer using the sqlite_user_data() API. |  | 
|   849  |  | 
|   850  The sixth, seventh and  eighth argumens, xFunc, xStep and xFinal, are |  | 
|   851  pointers to user implemented C functions that implement the user |  | 
|   852  function or aggregate. A scalar function requires an implementation of |  | 
|   853  the xFunc callback only, NULL pointers should be passed as the xStep |  | 
|   854  and xFinal arguments. An aggregate function requires an implementation |  | 
|   855  of xStep and xFinal, and NULL should be passed for xFunc. To delete an |  | 
|   856  existing user function or aggregate, pass NULL for all three function |  | 
|   857  callbacks. Specifying an inconstant set of callback values, such as an |  | 
|   858  xFunc and an xFinal, or an xStep but no xFinal, results in an SQLITE_ERROR |  | 
|   859  return. |  | 
|   860 } |  | 
|   861  |  | 
|   862 api {} { |  | 
|   863 int sqlite3_data_count(sqlite3_stmt *pStmt); |  | 
|   864 } { |  | 
|   865  Return the number of values in the current row of the result set. |  | 
|   866  |  | 
|   867  After a call to sqlite3_step() that returns SQLITE_ROW, this routine |  | 
|   868  will return the same value as the sqlite3_column_count() function. |  | 
|   869  After sqlite3_step() has returned an SQLITE_DONE, SQLITE_BUSY or |  | 
|   870  error code, or before sqlite3_step() has been called on a  |  | 
|   871  prepared SQL statement, this routine returns zero. |  | 
|   872 } |  | 
|   873  |  | 
|   874 api {} { |  | 
|   875 int sqlite3_errcode(sqlite3 *db); |  | 
|   876 } { |  | 
|   877  Return the error code for the most recent failed sqlite3_* API call associated |  | 
|   878  with sqlite3 handle 'db'.  If a prior API call failed but the most recent |  | 
|   879  API call succeeded, the return value from this routine is undefined.  |  | 
|   880  |  | 
|   881  Calls to many sqlite3_* functions set the error code and string returned |  | 
|   882  by sqlite3_errcode(), sqlite3_errmsg() and sqlite3_errmsg16() |  | 
|   883  (overwriting the previous values). Note that calls to sqlite3_errcode(), |  | 
|   884  sqlite3_errmsg() and sqlite3_errmsg16() themselves do not affect the |  | 
|   885  results of future invocations.  Calls to API routines that do not return |  | 
|   886  an error code (examples: sqlite3_data_count() or sqlite3_mprintf()) do |  | 
|   887  not change the error code returned by this routine. |  | 
|   888  |  | 
|   889  Assuming no other intervening sqlite3_* API calls are made, the error |  | 
|   890  code returned by this function is associated with the same error as |  | 
|   891  the strings returned by sqlite3_errmsg() and sqlite3_errmsg16(). |  | 
|   892 } {} |  | 
|   893  |  | 
|   894 api {} { |  | 
|   895 const char *sqlite3_errmsg(sqlite3*); |  | 
|   896 const void *sqlite3_errmsg16(sqlite3*); |  | 
|   897 } { |  | 
|   898  Return a pointer to a UTF-8 encoded string (sqlite3_errmsg) |  | 
|   899  or a UTF-16 encoded string (sqlite3_errmsg16) describing in English the |  | 
|   900  error condition for the most recent sqlite3_* API call. The returned |  | 
|   901  string is always terminated by an 0x00 byte. |  | 
|   902  |  | 
|   903  The string "not an error" is returned when the most recent API call was |  | 
|   904  successful. |  | 
|   905 } |  | 
|   906  |  | 
|   907 api {} { |  | 
|   908 int sqlite3_exec( |  | 
|   909   sqlite3*,                     /* An open database */ |  | 
|   910   const char *sql,              /* SQL to be executed */ |  | 
|   911   sqlite_callback,              /* Callback function */ |  | 
|   912   void *,                       /* 1st argument to callback function */ |  | 
|   913   char **errmsg                 /* Error msg written here */ |  | 
|   914 ); |  | 
|   915 } { |  | 
|   916  A function to executes one or more statements of SQL. |  | 
|   917  |  | 
|   918  If one or more of the SQL statements are queries, then |  | 
|   919  the callback function specified by the 3rd argument is |  | 
|   920  invoked once for each row of the query result.  This callback |  | 
|   921  should normally return 0.  If the callback returns a non-zero |  | 
|   922  value then the query is aborted, all subsequent SQL statements |  | 
|   923  are skipped and the sqlite3_exec() function returns the SQLITE_ABORT. |  | 
|   924  |  | 
|   925  The 1st argument is an arbitrary pointer that is passed |  | 
|   926  to the callback function as its first argument. |  | 
|   927  |  | 
|   928  The 2nd argument to the callback function is the number of |  | 
|   929  columns in the query result.  The 3rd argument to the callback |  | 
|   930  is an array of strings holding the values for each column. |  | 
|   931  The 4th argument to the callback is an array of strings holding |  | 
|   932  the names of each column. |  | 
|   933  |  | 
|   934  The callback function may be NULL, even for queries.  A NULL |  | 
|   935  callback is not an error.  It just means that no callback |  | 
|   936  will be invoked. |  | 
|   937  |  | 
|   938  If an error occurs while parsing or evaluating the SQL (but |  | 
|   939  not while executing the callback) then an appropriate error |  | 
|   940  message is written into memory obtained from malloc() and |  | 
|   941  *errmsg is made to point to that message.  The calling function |  | 
|   942  is responsible for freeing the memory that holds the error |  | 
|   943  message.   Use sqlite3_free() for this.  If errmsg==NULL, |  | 
|   944  then no error message is ever written. |  | 
|   945  |  | 
|   946  The return value is is SQLITE_OK if there are no errors and |  | 
|   947  some other return code if there is an error.  The particular |  | 
|   948  return value depends on the type of error.  |  | 
|   949  |  | 
|   950  If the query could not be executed because a database file is |  | 
|   951  locked or busy, then this function returns SQLITE_BUSY.  (This |  | 
|   952  behavior can be modified somewhat using the sqlite3_busy_handler() |  | 
|   953  and sqlite3_busy_timeout() functions.) |  | 
|   954 } {} |  | 
|   955  |  | 
|   956 api {} { |  | 
|   957 int sqlite3_finalize(sqlite3_stmt *pStmt); |  | 
|   958 } { |  | 
|   959  The sqlite3_finalize() function is called to delete a prepared |  | 
|   960  SQL statement obtained by a previous call to sqlite3_prepare(), |  | 
|   961  sqlite3_prepare_v2(), sqlite3_prepare16(), or sqlite3_prepare16_v2(). |  | 
|   962  If the statement was executed successfully, or |  | 
|   963  not executed at all, then SQLITE_OK is returned. If execution of the |  | 
|   964  statement failed then an error code is returned.  |  | 
|   965  |  | 
|   966  After sqlite_finalize() has been called, the statement handle is |  | 
|   967  invalidated. Passing it to any other SQLite function may cause a |  | 
|   968  crash. |  | 
|   969  |  | 
|   970  All prepared statements must finalized before sqlite3_close() is |  | 
|   971  called or else the close will fail with a return code of SQLITE_BUSY. |  | 
|   972  |  | 
|   973  This routine can be called at any point during the execution of the |  | 
|   974  virtual machine.  If the virtual machine has not completed execution |  | 
|   975  when this routine is called, that is like encountering an error or |  | 
|   976  an interrupt.  (See sqlite3_interrupt().)  Incomplete updates may be |  | 
|   977  rolled back and transactions canceled,  depending on the circumstances, |  | 
|   978  and the result code returned will be SQLITE_ABORT. |  | 
|   979 } |  | 
|   980  |  | 
|   981 api {} { |  | 
|   982 void *sqlite3_malloc(int); |  | 
|   983 void *sqlite3_realloc(void*, int); |  | 
|   984 void sqlite3_free(void*); |  | 
|   985 } { |  | 
|   986  These routines provide access to the memory allocator used by SQLite. |  | 
|   987  Depending on how SQLite has been compiled and the OS-layer backend, |  | 
|   988  the memory allocator used by SQLite might be the standard system |  | 
|   989  malloc()/realloc()/free(), or it might be something different.  With |  | 
|   990  certain compile-time flags, SQLite will add wrapper logic around the |  | 
|   991  memory allocator to add memory leak and buffer overrun detection.  The |  | 
|   992  OS layer might substitute a completely different memory allocator. |  | 
|   993  Use these APIs to be sure you are always using the correct memory |  | 
|   994  allocator. |  | 
|   995   |  | 
|   996  The sqlite3_free() API, not the standard free() from the system library, |  | 
|   997  should always be used to free the memory buffer returned by |  | 
|   998  sqlite3_mprintf() or sqlite3_vmprintf() and to free the error message |  | 
|   999  string returned by sqlite3_exec().  Using free() instead of sqlite3_free() |  | 
|  1000  might accidentally work on some systems and build configurations but  |  | 
|  1001  will fail on others. |  | 
|  1002  |  | 
|  1003  Compatibility Note:  Prior to version 3.4.0, the sqlite3_free API |  | 
|  1004  was prototyped to take a <tt>char*</tt> parameter rather than  |  | 
|  1005  <tt>void*</tt>.  Like this: |  | 
|  1006 <blockquote><pre> |  | 
|  1007 void sqlite3_free(char*); |  | 
|  1008 </pre></blockquote> |  | 
|  1009  The change to using <tt>void*</tt> might cause warnings when  |  | 
|  1010  compiling older code against |  | 
|  1011  newer libraries, but everything should still work correctly. |  | 
|  1012 } |  | 
|  1013  |  | 
|  1014 api {} { |  | 
|  1015 int sqlite3_get_table( |  | 
|  1016   sqlite3*,              /* An open database */ |  | 
|  1017   const char *sql,       /* SQL to be executed */ |  | 
|  1018   char ***resultp,       /* Result written to a char *[]  that this points to */ |  | 
|  1019   int *nrow,             /* Number of result rows written here */ |  | 
|  1020   int *ncolumn,          /* Number of result columns written here */ |  | 
|  1021   char **errmsg          /* Error msg written here */ |  | 
|  1022 ); |  | 
|  1023 void sqlite3_free_table(char **result); |  | 
|  1024 } { |  | 
|  1025  This next routine is really just a wrapper around sqlite3_exec(). |  | 
|  1026  Instead of invoking a user-supplied callback for each row of the |  | 
|  1027  result, this routine remembers each row of the result in memory |  | 
|  1028  obtained from malloc(), then returns all of the result after the |  | 
|  1029  query has finished.  |  | 
|  1030  |  | 
|  1031  As an example, suppose the query result where this table: |  | 
|  1032  |  | 
|  1033  <pre> |  | 
|  1034         Name        | Age |  | 
|  1035         ----------------------- |  | 
|  1036         Alice       | 43 |  | 
|  1037         Bob         | 28 |  | 
|  1038         Cindy       | 21 |  | 
|  1039  </pre> |  | 
|  1040  |  | 
|  1041  If the 3rd argument were &azResult then after the function returns |  | 
|  1042  azResult will contain the following data: |  | 
|  1043  |  | 
|  1044  <pre> |  | 
|  1045         azResult[0] = "Name"; |  | 
|  1046         azResult[1] = "Age"; |  | 
|  1047         azResult[2] = "Alice"; |  | 
|  1048         azResult[3] = "43"; |  | 
|  1049         azResult[4] = "Bob"; |  | 
|  1050         azResult[5] = "28"; |  | 
|  1051         azResult[6] = "Cindy"; |  | 
|  1052         azResult[7] = "21"; |  | 
|  1053  </pre> |  | 
|  1054  |  | 
|  1055  Notice that there is an extra row of data containing the column |  | 
|  1056  headers.  But the *nrow return value is still 3.  *ncolumn is |  | 
|  1057  set to 2.  In general, the number of values inserted into azResult |  | 
|  1058  will be ((*nrow) + 1)*(*ncolumn). |  | 
|  1059  |  | 
|  1060  After the calling function has finished using the result, it should  |  | 
|  1061  pass the result data pointer to sqlite3_free_table() in order to  |  | 
|  1062  release the memory that was malloc-ed.  Because of the way the  |  | 
|  1063  malloc() happens, the calling function must not try to call  |  | 
|  1064  malloc() directly.  Only sqlite3_free_table() is able to release  |  | 
|  1065  the memory properly and safely. |  | 
|  1066  |  | 
|  1067  The return value of this routine is the same as from sqlite3_exec(). |  | 
|  1068 } |  | 
|  1069  |  | 
|  1070 api {sqlite3_interrupt} { |  | 
|  1071  void sqlite3_interrupt(sqlite3*); |  | 
|  1072 } { |  | 
|  1073  This function causes any pending database operation to abort and |  | 
|  1074  return at its earliest opportunity.  This routine is typically |  | 
|  1075  called in response to a user action such as pressing "Cancel" |  | 
|  1076  or Ctrl-C where the user wants a long query operation to halt |  | 
|  1077  immediately. |  | 
|  1078 } {} |  | 
|  1079  |  | 
|  1080 api {} { |  | 
|  1081 long long int sqlite3_last_insert_rowid(sqlite3*); |  | 
|  1082 } { |  | 
|  1083  Each entry in an SQLite table has a unique integer key called the "rowid". |  | 
|  1084  The rowid is always available as an undeclared column |  | 
|  1085  named ROWID, OID, or _ROWID_. |  | 
|  1086  If the table has a column of type INTEGER PRIMARY KEY then that column |  | 
|  1087  is another an alias for the rowid. |  | 
|  1088  |  | 
|  1089  This routine |  | 
|  1090  returns the rowid of the most recent INSERT into the database |  | 
|  1091  from the database connection given in the first argument.  If |  | 
|  1092  no inserts have ever occurred on this database connection, zero |  | 
|  1093  is returned. |  | 
|  1094  |  | 
|  1095  If an INSERT occurs within a trigger, then the rowid of the |  | 
|  1096  inserted row is returned by this routine as long as the trigger |  | 
|  1097  is running.  But once the trigger terminates, the value returned |  | 
|  1098  by this routine reverts to the last value inserted before the |  | 
|  1099  trigger fired. |  | 
|  1100 } {} |  | 
|  1101  |  | 
|  1102 api {} { |  | 
|  1103 char *sqlite3_mprintf(const char*,...); |  | 
|  1104 char *sqlite3_vmprintf(const char*, va_list); |  | 
|  1105 } { |  | 
|  1106  These routines are variants of the "sprintf()" from the |  | 
|  1107  standard C library.  The resulting string is written into memory |  | 
|  1108  obtained from malloc() so that there is never a possibility of buffer |  | 
|  1109  overflow.  These routines also implement some additional formatting |  | 
|  1110  options that are useful for constructing SQL statements. |  | 
|  1111  |  | 
|  1112  The strings returned by these routines should be freed by calling |  | 
|  1113  sqlite3_free(). |  | 
|  1114  |  | 
|  1115  All of the usual printf formatting options apply.  In addition, there |  | 
|  1116  is a "%q" option.  %q works like %s in that it substitutes a null-terminated |  | 
|  1117  string from the argument list.  But %q also doubles every '\\'' character. |  | 
|  1118  %q is designed for use inside a string literal.  By doubling each '\\'' |  | 
|  1119  character it escapes that character and allows it to be inserted into |  | 
|  1120  the string. |  | 
|  1121  |  | 
|  1122  For example, so some string variable contains text as follows: |  | 
|  1123  |  | 
|  1124  <blockquote><pre> |  | 
|  1125   char *zText = "It's a happy day!"; |  | 
|  1126  </pre></blockquote> |  | 
|  1127  |  | 
|  1128  One can use this text in an SQL statement as follows: |  | 
|  1129  |  | 
|  1130  <blockquote><pre> |  | 
|  1131   sqlite3_exec_printf(db, "INSERT INTO table VALUES('%q')", |  | 
|  1132        callback1, 0, 0, zText); |  | 
|  1133   </pre></blockquote> |  | 
|  1134  |  | 
|  1135  Because the %q format string is used, the '\\'' character in zText |  | 
|  1136  is escaped and the SQL generated is as follows: |  | 
|  1137  |  | 
|  1138  <blockquote><pre> |  | 
|  1139   INSERT INTO table1 VALUES('It''s a happy day!') |  | 
|  1140  </pre></blockquote> |  | 
|  1141  |  | 
|  1142  This is correct.  Had we used %s instead of %q, the generated SQL |  | 
|  1143  would have looked like this: |  | 
|  1144  |  | 
|  1145   <blockquote><pre> |  | 
|  1146   INSERT INTO table1 VALUES('It's a happy day!'); |  | 
|  1147   </pre></blockquote> |  | 
|  1148  |  | 
|  1149  This second example is an SQL syntax error.  As a general rule you |  | 
|  1150  should always use %q instead of %s when inserting text into a string  |  | 
|  1151  literal. |  | 
|  1152 } {} |  | 
|  1153  |  | 
|  1154 api {} { |  | 
|  1155 char *sqlite3_snprintf(int bufSize, char *buf, const char *zFormat, ...); |  | 
|  1156 } { |  | 
|  1157   This routine works like "sprintf()", writing a formatted string into |  | 
|  1158   the buf[].  However, no more than bufSize characters will be written |  | 
|  1159   into buf[].  This routine returns a pointer to buf[].  If bufSize is |  | 
|  1160   greater than zero, then buf[] is guaranteed to be zero-terminated. |  | 
|  1161  |  | 
|  1162   This routine uses the same extended formatting options as |  | 
|  1163   sqlite3_mprintf() and sqlite3_vmprintf(). |  | 
|  1164  |  | 
|  1165   Note these differences with the snprintf() function found in many |  | 
|  1166   standard libraries:  (1)  sqlite3_snprintf() returns a pointer to the |  | 
|  1167   buffer rather than the number of characters written.  (It would, |  | 
|  1168   arguably, be more useful to return the number of characters written, |  | 
|  1169   but we discovered that after the interface had been published and |  | 
|  1170   are unwilling to break backwards compatibility.)  (2)  The order |  | 
|  1171   of the bufSize and buf parameter is reversed from snprintf().   |  | 
|  1172   And (3) sqlite3_snprintf() always writes a zero-terminator if bufSize |  | 
|  1173   is positive.   |  | 
|  1174  |  | 
|  1175   Please do not use the return value of this routine.  We may |  | 
|  1176   decide to make the minor compatibility break and change this routine |  | 
|  1177   to return the number of characters written rather than a pointer to |  | 
|  1178   the buffer in a future minor version increment. |  | 
|  1179 } |  | 
|  1180  |  | 
|  1181 api {} { |  | 
|  1182 int sqlite3_open( |  | 
|  1183   const char *filename,   /* Database filename (UTF-8) */ |  | 
|  1184   sqlite3 **ppDb          /* OUT: SQLite db handle */ |  | 
|  1185 ); |  | 
|  1186 int sqlite3_open16( |  | 
|  1187   const void *filename,   /* Database filename (UTF-16) */ |  | 
|  1188   sqlite3 **ppDb          /* OUT: SQLite db handle */ |  | 
|  1189 ); |  | 
|  1190 } { |  | 
|  1191  Open the sqlite database file "filename".  The "filename" is UTF-8 |  | 
|  1192  encoded for sqlite3_open() and UTF-16 encoded in the native byte order |  | 
|  1193  for sqlite3_open16().  An sqlite3* handle is returned in *ppDb, even |  | 
|  1194  if an error occurs. If the database is opened (or created) successfully, |  | 
|  1195  then SQLITE_OK is returned. Otherwise an error code is returned. The |  | 
|  1196  sqlite3_errmsg() or sqlite3_errmsg16()  routines can be used to obtain |  | 
|  1197  an English language description of the error. |  | 
|  1198  |  | 
|  1199  If the database file does not exist, then a new database will be created |  | 
|  1200  as needed. |  | 
|  1201  The encoding for the database will be UTF-8 if sqlite3_open() is called and |  | 
|  1202  UTF-16 if sqlite3_open16 is used. |  | 
|  1203  |  | 
|  1204  Whether or not an error occurs when it is opened, resources associated |  | 
|  1205  with the sqlite3* handle should be released by passing it to |  | 
|  1206  sqlite3_close() when it is no longer required. |  | 
|  1207  |  | 
|  1208  The returned sqlite3* can only be used in the same thread in which it |  | 
|  1209  was created.  It is an error to call sqlite3_open() in one thread then |  | 
|  1210  pass the resulting database handle off to another thread to use.  This |  | 
|  1211  restriction is due to goofy design decisions (bugs?) in the way some |  | 
|  1212  threading implementations interact with file locks. |  | 
|  1213  |  | 
|  1214  Note to windows users:  The encoding used for the filename argument |  | 
|  1215  of sqlite3_open() must be UTF-8, not whatever codepage is currently |  | 
|  1216  defined.  Filenames containing international characters must be converted |  | 
|  1217  to UTF-8 prior to passing them into sqlite3_open(). |  | 
|  1218 } |  | 
|  1219  |  | 
|  1220 api {} { |  | 
|  1221 int sqlite3_prepare_v2( |  | 
|  1222   sqlite3 *db,            /* Database handle */ |  | 
|  1223   const char *zSql,       /* SQL statement, UTF-8 encoded */ |  | 
|  1224   int nBytes,             /* Length of zSql in bytes. */ |  | 
|  1225   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */ |  | 
|  1226   const char **pzTail     /* OUT: Pointer to unused portion of zSql */ |  | 
|  1227 ); |  | 
|  1228 int sqlite3_prepare16_v2( |  | 
|  1229   sqlite3 *db,            /* Database handle */ |  | 
|  1230   const void *zSql,       /* SQL statement, UTF-16 encoded */ |  | 
|  1231   int nBytes,             /* Length of zSql in bytes. */ |  | 
|  1232   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */ |  | 
|  1233   const void **pzTail     /* OUT: Pointer to unused portion of zSql */ |  | 
|  1234 ); |  | 
|  1235  |  | 
|  1236 /* Legacy Interfaces */ |  | 
|  1237 int sqlite3_prepare( |  | 
|  1238   sqlite3 *db,            /* Database handle */ |  | 
|  1239   const char *zSql,       /* SQL statement, UTF-8 encoded */ |  | 
|  1240   int nBytes,             /* Length of zSql in bytes. */ |  | 
|  1241   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */ |  | 
|  1242   const char **pzTail     /* OUT: Pointer to unused portion of zSql */ |  | 
|  1243 ); |  | 
|  1244 int sqlite3_prepare16( |  | 
|  1245   sqlite3 *db,            /* Database handle */ |  | 
|  1246   const void *zSql,       /* SQL statement, UTF-16 encoded */ |  | 
|  1247   int nBytes,             /* Length of zSql in bytes. */ |  | 
|  1248   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */ |  | 
|  1249   const void **pzTail     /* OUT: Pointer to unused portion of zSql */ |  | 
|  1250 ); |  | 
|  1251 } { |  | 
|  1252  To execute an SQL query, it must first be compiled into a byte-code |  | 
|  1253  program using one of these routines.  |  | 
|  1254  |  | 
|  1255  The first argument "db" is an SQLite database handle. The second |  | 
|  1256  argument "zSql" is the statement to be compiled, encoded as either |  | 
|  1257  UTF-8 or UTF-16.  The sqlite3_prepare_v2() |  | 
|  1258  interfaces uses UTF-8 and sqlite3_prepare16_v2() |  | 
|  1259  use UTF-16. If the next argument, "nBytes", is less |  | 
|  1260  than zero, then zSql is read up to the first nul terminator.  If |  | 
|  1261  "nBytes" is not less than zero, then it is the length of the string zSql |  | 
|  1262  in bytes (not characters). |  | 
|  1263  |  | 
|  1264  *pzTail is made to point to the first byte past the end of the first |  | 
|  1265  SQL statement in zSql.  This routine only compiles the first statement |  | 
|  1266  in zSql, so *pzTail is left pointing to what remains uncompiled. |  | 
|  1267  |  | 
|  1268  *ppStmt is left pointing to a compiled SQL statement that can be |  | 
|  1269  executed using sqlite3_step().  Or if there is an error, *ppStmt may be |  | 
|  1270  set to NULL.  If the input text contained no SQL (if the input is and |  | 
|  1271  empty string or a comment) then *ppStmt is set to NULL.  The calling |  | 
|  1272  procedure is responsible for deleting this compiled SQL statement |  | 
|  1273  using sqlite3_finalize() after it has finished with it. |  | 
|  1274  |  | 
|  1275  On success, SQLITE_OK is returned.  Otherwise an error code is returned. |  | 
|  1276  |  | 
|  1277  The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are |  | 
|  1278  recommended for all new programs. The two older interfaces are retained |  | 
|  1279  for backwards compatibility, but their use is discouraged. |  | 
|  1280  In the "v2" interfaces, the prepared statement |  | 
|  1281  that is returned (the sqlite3_stmt object) contains a copy of the original |  | 
|  1282  SQL. This causes the sqlite3_step() interface to behave a differently in |  | 
|  1283  two ways: |  | 
|  1284  |  | 
|  1285  <ol> |  | 
|  1286  <li> |  | 
|  1287  If the database schema changes, instead of returning SQLITE_SCHEMA as it |  | 
|  1288  always used to do, sqlite3_step() will automatically recompile the SQL |  | 
|  1289  statement and try to run it again.  If the schema has changed in a way |  | 
|  1290  that makes the statement no longer valid, sqlite3_step() will still |  | 
|  1291  return SQLITE_SCHEMA.  But unlike the legacy behavior, SQLITE_SCHEMA is |  | 
|  1292  now a fatal error.  Calling sqlite3_prepare_v2() again will not make the |  | 
|  1293  error go away.  Note: use sqlite3_errmsg() to find the text of the parsing |  | 
|  1294  error that results in an SQLITE_SCHEMA return. |  | 
|  1295  </li> |  | 
|  1296  |  | 
|  1297  <li> |  | 
|  1298  When an error occurs,  |  | 
|  1299  sqlite3_step() will return one of the detailed result-codes |  | 
|  1300  like SQLITE_IOERR or SQLITE_FULL or SQLITE_SCHEMA directly. The |  | 
|  1301  legacy behavior was that sqlite3_step() would only return a generic |  | 
|  1302  SQLITE_ERROR code and you would have to make a second call to |  | 
|  1303  sqlite3_reset() in order to find the underlying cause of the problem. |  | 
|  1304  With the "v2" prepare interfaces, the underlying reason for the error is |  | 
|  1305  returned directly. |  | 
|  1306  </li> |  | 
|  1307  </ol> |  | 
|  1308 } |  | 
|  1309  |  | 
|  1310 api {} { |  | 
|  1311 void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*); |  | 
|  1312 } { |  | 
|  1313  <i>Experimental</i> |  | 
|  1314  |  | 
|  1315  This routine configures a callback function - the progress callback - that |  | 
|  1316  is invoked periodically during long running calls to sqlite3_exec(), |  | 
|  1317  sqlite3_step() and sqlite3_get_table(). |  | 
|  1318  An example use for this API is to keep |  | 
|  1319  a GUI updated during a large query. |  | 
|  1320  |  | 
|  1321  The progress callback is invoked once for every N virtual machine opcodes, |  | 
|  1322  where N is the second argument to this function. The progress callback |  | 
|  1323  itself is identified by the third argument to this function. The fourth |  | 
|  1324  argument to this function is a void pointer passed to the progress callback |  | 
|  1325  function each time it is invoked. |  | 
|  1326  |  | 
|  1327  If a call to sqlite3_exec(), sqlite3_step() or sqlite3_get_table() results  |  | 
|  1328  in less than N opcodes being executed, then the progress callback is not |  | 
|  1329  invoked. |  | 
|  1330   |  | 
|  1331  To remove the progress callback altogether, pass NULL as the third |  | 
|  1332  argument to this function. |  | 
|  1333  |  | 
|  1334  If the progress callback returns a result other than 0, then the current  |  | 
|  1335  query is immediately terminated and any database changes rolled back. If the |  | 
|  1336  query was part of a larger transaction, then the transaction is not rolled |  | 
|  1337  back and remains active. The sqlite3_exec() call returns SQLITE_ABORT.  |  | 
|  1338  |  | 
|  1339 } |  | 
|  1340  |  | 
|  1341 api {} { |  | 
|  1342 int sqlite3_reset(sqlite3_stmt *pStmt); |  | 
|  1343 } { |  | 
|  1344  The sqlite3_reset() function is called to reset a prepared SQL |  | 
|  1345  statement obtained by a previous call to  |  | 
|  1346  sqlite3_prepare_v2() or |  | 
|  1347  sqlite3_prepare16_v2() back to it's initial state, ready to be re-executed. |  | 
|  1348  Any SQL statement variables that had values bound to them using |  | 
|  1349  the sqlite3_bind_*() API retain their values. |  | 
|  1350 } |  | 
|  1351  |  | 
|  1352 api {} { |  | 
|  1353 void sqlite3_result_blob(sqlite3_context*, const void*, int n, void(*)(void*)); |  | 
|  1354 void sqlite3_result_double(sqlite3_context*, double); |  | 
|  1355 void sqlite3_result_error(sqlite3_context*, const char*, int); |  | 
|  1356 void sqlite3_result_error16(sqlite3_context*, const void*, int); |  | 
|  1357 void sqlite3_result_int(sqlite3_context*, int); |  | 
|  1358 void sqlite3_result_int64(sqlite3_context*, long long int); |  | 
|  1359 void sqlite3_result_null(sqlite3_context*); |  | 
|  1360 void sqlite3_result_text(sqlite3_context*, const char*, int n, void(*)(void*)); |  | 
|  1361 void sqlite3_result_text16(sqlite3_context*, const void*, int n, void(*)(void*))
      ; |  | 
|  1362 void sqlite3_result_text16be(sqlite3_context*, const void*, int n, void(*)(void*
      )); |  | 
|  1363 void sqlite3_result_text16le(sqlite3_context*, const void*, int n, void(*)(void*
      )); |  | 
|  1364 void sqlite3_result_value(sqlite3_context*, sqlite3_value*); |  | 
|  1365 } { |  | 
|  1366  User-defined functions invoke these routines in order to |  | 
|  1367  set their return value.  The sqlite3_result_value() routine is used |  | 
|  1368  to return an exact copy of one of the arguments to the function. |  | 
|  1369  |  | 
|  1370  The operation of these routines is very similar to the operation of |  | 
|  1371  sqlite3_bind_blob() and its cousins.  Refer to the documentation there |  | 
|  1372  for additional information. |  | 
|  1373 } |  | 
|  1374  |  | 
|  1375 api {} { |  | 
|  1376 int sqlite3_set_authorizer( |  | 
|  1377   sqlite3*, |  | 
|  1378   int (*xAuth)(void*,int,const char*,const char*,const char*,const char*), |  | 
|  1379   void *pUserData |  | 
|  1380 ); |  | 
|  1381 #define SQLITE_CREATE_INDEX          1   /* Index Name      Table Name      */ |  | 
|  1382 #define SQLITE_CREATE_TABLE          2   /* Table Name      NULL            */ |  | 
|  1383 #define SQLITE_CREATE_TEMP_INDEX     3   /* Index Name      Table Name      */ |  | 
|  1384 #define SQLITE_CREATE_TEMP_TABLE     4   /* Table Name      NULL            */ |  | 
|  1385 #define SQLITE_CREATE_TEMP_TRIGGER   5   /* Trigger Name    Table Name      */ |  | 
|  1386 #define SQLITE_CREATE_TEMP_VIEW      6   /* View Name       NULL            */ |  | 
|  1387 #define SQLITE_CREATE_TRIGGER        7   /* Trigger Name    Table Name      */ |  | 
|  1388 #define SQLITE_CREATE_VIEW           8   /* View Name       NULL            */ |  | 
|  1389 #define SQLITE_DELETE                9   /* Table Name      NULL            */ |  | 
|  1390 #define SQLITE_DROP_INDEX           10   /* Index Name      Table Name      */ |  | 
|  1391 #define SQLITE_DROP_TABLE           11   /* Table Name      NULL            */ |  | 
|  1392 #define SQLITE_DROP_TEMP_INDEX      12   /* Index Name      Table Name      */ |  | 
|  1393 #define SQLITE_DROP_TEMP_TABLE      13   /* Table Name      NULL            */ |  | 
|  1394 #define SQLITE_DROP_TEMP_TRIGGER    14   /* Trigger Name    Table Name      */ |  | 
|  1395 #define SQLITE_DROP_TEMP_VIEW       15   /* View Name       NULL            */ |  | 
|  1396 #define SQLITE_DROP_TRIGGER         16   /* Trigger Name    Table Name      */ |  | 
|  1397 #define SQLITE_DROP_VIEW            17   /* View Name       NULL            */ |  | 
|  1398 #define SQLITE_INSERT               18   /* Table Name      NULL            */ |  | 
|  1399 #define SQLITE_PRAGMA               19   /* Pragma Name     1st arg or NULL */ |  | 
|  1400 #define SQLITE_READ                 20   /* Table Name      Column Name     */ |  | 
|  1401 #define SQLITE_SELECT               21   /* NULL            NULL            */ |  | 
|  1402 #define SQLITE_TRANSACTION          22   /* NULL            NULL            */ |  | 
|  1403 #define SQLITE_UPDATE               23   /* Table Name      Column Name     */ |  | 
|  1404 #define SQLITE_ATTACH               24   /* Filename        NULL            */ |  | 
|  1405 #define SQLITE_DETACH               25   /* Database Name   NULL            */ |  | 
|  1406 #define SQLITE_ALTER_TABLE          26   /* Database Name   Table Name      */ |  | 
|  1407 #define SQLITE_REINDEX              27   /* Index Name      NULL            */ |  | 
|  1408 #define SQLITE_ANALYZE              28   /* Table Name      NULL            */ |  | 
|  1409 #define SQLITE_CREATE_VTABLE        29   /* Table Name      Module Name     */ |  | 
|  1410 #define SQLITE_DROP_VTABLE          30   /* Table Name      Module Name     */ |  | 
|  1411 #define SQLITE_FUNCTION             31   /* Function Name   NULL            */ |  | 
|  1412  |  | 
|  1413 #define SQLITE_DENY   1   /* Abort the SQL statement with an error */ |  | 
|  1414 #define SQLITE_IGNORE 2   /* Don't allow access, but don't generate an error */ |  | 
|  1415 } { |  | 
|  1416  This routine registers a callback with the SQLite library.  The |  | 
|  1417  callback is invoked by sqlite3_prepare_v2() to authorize various |  | 
|  1418  operations against the database.  The callback should |  | 
|  1419  return SQLITE_OK if access is allowed, SQLITE_DENY if the entire |  | 
|  1420  SQL statement should be aborted with an error and SQLITE_IGNORE |  | 
|  1421  if the operation should be treated as a no-op. |  | 
|  1422  |  | 
|  1423  Each database connection have at most one authorizer registered |  | 
|  1424  at a time one time.  Each call |  | 
|  1425  to sqlite3_set_authorizer() overrides the previous authorizer. |  | 
|  1426  Setting the callback to NULL disables the authorizer. |  | 
|  1427  |  | 
|  1428  The second argument to the access authorization function will be one |  | 
|  1429  of the defined constants shown.  These values signify what kind of operation |  | 
|  1430  is to be authorized.  The 3rd and 4th arguments to the authorization |  | 
|  1431  function will be arguments or NULL depending on which of the  |  | 
|  1432  codes is used as the second argument.  For example, if the the |  | 
|  1433  2nd argument code is SQLITE_READ then the 3rd argument will be the name |  | 
|  1434  of the table that is being read from and the 4th argument will be the |  | 
|  1435  name of the column that is being read from.  Or if the 2nd argument |  | 
|  1436  is SQLITE_FUNCTION then the 3rd argument will be the name of the |  | 
|  1437  function that is being invoked and the 4th argument will be NULL. |  | 
|  1438  |  | 
|  1439  The 5th argument is the name |  | 
|  1440  of the database ("main", "temp", etc.) where applicable.  The 6th argument |  | 
|  1441  is the name of the inner-most trigger or view that is responsible for |  | 
|  1442  the access attempt or NULL if this access attempt is directly from  |  | 
|  1443  input SQL code. |  | 
|  1444  |  | 
|  1445  The return value of the authorization callback function should be one of the |  | 
|  1446  constants SQLITE_OK, SQLITE_DENY, or SQLITE_IGNORE.  A return of |  | 
|  1447  SQLITE_OK means that the operation is permitted and that  |  | 
|  1448  sqlite3_prepare_v2() can proceed as normal. |  | 
|  1449  A return of SQLITE_DENY means that the sqlite3_prepare_v2() |  | 
|  1450  should fail with an error.  A return of SQLITE_IGNORE causes the  |  | 
|  1451  sqlite3_prepare_v2() to continue as normal but the requested  |  | 
|  1452  operation is silently converted into a no-op.  A return of SQLITE_IGNORE |  | 
|  1453  in response to an SQLITE_READ or SQLITE_FUNCTION causes the column |  | 
|  1454  being read or the function being invoked to return a NULL. |  | 
|  1455  |  | 
|  1456  The intent of this routine is to allow applications to safely execute |  | 
|  1457  user-entered SQL.  An appropriate callback can deny the user-entered |  | 
|  1458  SQL access certain operations (ex: anything that changes the database) |  | 
|  1459  or to deny access to certain tables or columns within the database. |  | 
|  1460  |  | 
|  1461  SQLite is not reentrant through the authorization callback function. |  | 
|  1462  The authorization callback function should not attempt to invoke |  | 
|  1463  any other SQLite APIs for the same database connection.  If the |  | 
|  1464  authorization callback function invokes some other SQLite API, an |  | 
|  1465  SQLITE_MISUSE error or a segmentation fault may result. |  | 
|  1466 } |  | 
|  1467  |  | 
|  1468 api {} { |  | 
|  1469 int sqlite3_step(sqlite3_stmt*); |  | 
|  1470 } { |  | 
|  1471  After an SQL query has been prepared with a call to either |  | 
|  1472  sqlite3_prepare_v2() or sqlite3_prepare16_v2() or to one of |  | 
|  1473  the legacy interfaces sqlite3_prepare() or sqlite3_prepare16(), |  | 
|  1474  then this function must be |  | 
|  1475  called one or more times to execute the statement. |  | 
|  1476  |  | 
|  1477  The details of the behavior of this sqlite3_step() interface depend |  | 
|  1478  on whether the statement was prepared using the newer "v2" interface |  | 
|  1479  sqlite3_prepare_v2() and sqlite3_prepare16_v2() or the older legacy |  | 
|  1480  interface sqlite3_prepare() and sqlite3_prepare16().  The use of the |  | 
|  1481  new "v2" interface is recommended for new applications but the legacy |  | 
|  1482  interface will continue to be supported. |  | 
|  1483  |  | 
|  1484  In the lagacy interface, the return value will be either SQLITE_BUSY,  |  | 
|  1485  SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR, or SQLITE_MISUSE.  With the "v2" |  | 
|  1486  interface, any of the other SQLite result-codes might be returned as |  | 
|  1487  well. |  | 
|  1488  |  | 
|  1489  SQLITE_BUSY means that the database engine attempted to open |  | 
|  1490  a locked database and there is no busy callback registered. |  | 
|  1491  Call sqlite3_step() again to retry the open. |  | 
|  1492  |  | 
|  1493  SQLITE_DONE means that the statement has finished executing |  | 
|  1494  successfully.  sqlite3_step() should not be called again on this virtual |  | 
|  1495  machine without first calling sqlite3_reset() to reset the virtual |  | 
|  1496  machine back to its initial state. |  | 
|  1497  |  | 
|  1498  If the SQL statement being executed returns any data, then  |  | 
|  1499  SQLITE_ROW is returned each time a new row of data is ready |  | 
|  1500  for processing by the caller. The values may be accessed using |  | 
|  1501  the sqlite3_column_int(), sqlite3_column_text(), and similar functions. |  | 
|  1502  sqlite3_step() is called again to retrieve the next row of data. |  | 
|  1503   |  | 
|  1504  SQLITE_ERROR means that a run-time error (such as a constraint |  | 
|  1505  violation) has occurred.  sqlite3_step() should not be called again on |  | 
|  1506  the VM. More information may be found by calling sqlite3_errmsg(). |  | 
|  1507  A more specific error code (example: SQLITE_INTERRUPT, SQLITE_SCHEMA, |  | 
|  1508  SQLITE_CORRUPT, and so forth) can be obtained by calling |  | 
|  1509  sqlite3_reset() on the prepared statement.  In the "v2" interface, |  | 
|  1510  the more specific error code is returned directly by sqlite3_step(). |  | 
|  1511  |  | 
|  1512  SQLITE_MISUSE means that the this routine was called inappropriately. |  | 
|  1513  Perhaps it was called on a virtual machine that had already been |  | 
|  1514  finalized or on one that had previously returned SQLITE_ERROR or |  | 
|  1515  SQLITE_DONE.  Or it could be the case that a database connection |  | 
|  1516  is being used by a different thread than the one it was created it. |  | 
|  1517  |  | 
|  1518  <b>Goofy Interface Alert:</b> |  | 
|  1519  In the legacy interface,  |  | 
|  1520  the sqlite3_step() API always returns a generic error code, |  | 
|  1521  SQLITE_ERROR, following any error other than SQLITE_BUSY and SQLITE_MISUSE. |  | 
|  1522  You must call sqlite3_reset() (or sqlite3_finalize()) in order to find |  | 
|  1523  one of the specific result-codes that better describes the error. |  | 
|  1524  We admit that this is a goofy design.  The problem has been fixed |  | 
|  1525  with the "v2" interface.  If you prepare all of your SQL statements |  | 
|  1526  using either sqlite3_prepare_v2() or sqlite3_prepare16_v2() instead |  | 
|  1527  of the legacy sqlite3_prepare() and sqlite3_prepare16(), then the  |  | 
|  1528  more specific result-codes are returned directly by sqlite3_step(). |  | 
|  1529  The use of the "v2" interface is recommended. |  | 
|  1530 } |  | 
|  1531  |  | 
|  1532 api {} { |  | 
|  1533 void *sqlite3_trace(sqlite3*, void(*xTrace)(void*,const char*), void*); |  | 
|  1534 } { |  | 
|  1535  Register a function that is called each time an SQL statement is evaluated. |  | 
|  1536  The callback function is invoked on the first call to sqlite3_step() after |  | 
|  1537  calls to sqlite3_prepare_v2() or sqlite3_reset(). |  | 
|  1538  This function can be used (for example) to generate |  | 
|  1539  a log file of all SQL executed against a database.  This can be |  | 
|  1540  useful when debugging an application that uses SQLite. |  | 
|  1541 } |  | 
|  1542  |  | 
|  1543 api {} { |  | 
|  1544 void *sqlite3_user_data(sqlite3_context*); |  | 
|  1545 } { |  | 
|  1546  The pUserData argument to the sqlite3_create_function() and |  | 
|  1547  sqlite3_create_function16() routines used to register user functions |  | 
|  1548  is available to the implementation of the function using this |  | 
|  1549  call. |  | 
|  1550 } |  | 
|  1551  |  | 
|  1552 api {} { |  | 
|  1553 const void *sqlite3_value_blob(sqlite3_value*); |  | 
|  1554 int sqlite3_value_bytes(sqlite3_value*); |  | 
|  1555 int sqlite3_value_bytes16(sqlite3_value*); |  | 
|  1556 double sqlite3_value_double(sqlite3_value*); |  | 
|  1557 int sqlite3_value_int(sqlite3_value*); |  | 
|  1558 long long int sqlite3_value_int64(sqlite3_value*); |  | 
|  1559 const unsigned char *sqlite3_value_text(sqlite3_value*); |  | 
|  1560 const void *sqlite3_value_text16(sqlite3_value*); |  | 
|  1561 const void *sqlite3_value_text16be(sqlite3_value*); |  | 
|  1562 const void *sqlite3_value_text16le(sqlite3_value*); |  | 
|  1563 int sqlite3_value_type(sqlite3_value*); |  | 
|  1564 } { |  | 
|  1565  This group of routines returns information about arguments to |  | 
|  1566  a user-defined function.  Function implementations use these routines |  | 
|  1567  to access their arguments.  These routines are the same as the |  | 
|  1568  sqlite3_column_... routines except that these routines take a single |  | 
|  1569  sqlite3_value* pointer instead of an sqlite3_stmt* and an integer |  | 
|  1570  column number. |  | 
|  1571  |  | 
|  1572  See the documentation under sqlite3_column_blob for additional |  | 
|  1573  information. |  | 
|  1574  |  | 
|  1575  Please pay particular attention to the fact that the pointer that |  | 
|  1576  is returned from sqlite3_value_blob(), sqlite3_value_text(), or |  | 
|  1577  sqlite3_value_text16() can be invalidated by a subsequent call to |  | 
|  1578  sqlite3_value_bytes(), sqlite3_value_bytes16(), sqlite_value_text(), |  | 
|  1579  or sqlite3_value_text16().   |  | 
|  1580 } |  | 
|  1581  |  | 
|  1582 api {} { |  | 
|  1583   int sqlite3_sleep(int); |  | 
|  1584 } { |  | 
|  1585  Sleep for a little while. The second parameter is the number of |  | 
|  1586  miliseconds to sleep for.  |  | 
|  1587  |  | 
|  1588  If the operating system does not support sleep requests with  |  | 
|  1589  milisecond time resolution, then the time will be rounded up to  |  | 
|  1590  the nearest second. The number of miliseconds of sleep actually  |  | 
|  1591  requested from the operating system is returned. |  | 
|  1592 } |  | 
|  1593  |  | 
|  1594 api {} { |  | 
|  1595   int sqlite3_expired(sqlite3_stmt*); |  | 
|  1596 } { |  | 
|  1597  Return TRUE (non-zero) if the statement supplied as an argument needs |  | 
|  1598  to be recompiled.  A statement needs to be recompiled whenever the |  | 
|  1599  execution environment changes in a way that would alter the program |  | 
|  1600  that sqlite3_prepare() generates.  For example, if new functions or |  | 
|  1601  collating sequences are registered or if an authorizer function is |  | 
|  1602  added or changed. |  | 
|  1603 } |  | 
|  1604  |  | 
|  1605 api {} { |  | 
|  1606   int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*); |  | 
|  1607 } { |  | 
|  1608  Move all bindings from the first prepared statement over to the second. |  | 
|  1609  This routine is useful, for example, if the first prepared statement |  | 
|  1610  fails with an SQLITE_SCHEMA error.  The same SQL can be prepared into |  | 
|  1611  the second prepared statement then all of the bindings transfered over |  | 
|  1612  to the second statement before the first statement is finalized. |  | 
|  1613 } |  | 
|  1614  |  | 
|  1615 api {} { |  | 
|  1616   int sqlite3_global_recover(); |  | 
|  1617 } { |  | 
|  1618  This function used to be involved in recovering from out-of-memory |  | 
|  1619  errors.  But as of SQLite version 3.3.0, out-of-memory recovery is |  | 
|  1620  automatic and this routine now does nothing.  THe interface is retained |  | 
|  1621  to avoid link errors with legacy code. |  | 
|  1622 } |  | 
|  1623  |  | 
|  1624 api {} { |  | 
|  1625   int sqlite3_get_autocommit(sqlite3*); |  | 
|  1626 } { |  | 
|  1627  Test to see whether or not the database connection is in autocommit |  | 
|  1628  mode.  Return TRUE if it is and FALSE if not.  Autocommit mode is on |  | 
|  1629  by default.  Autocommit is disabled by a BEGIN statement and reenabled |  | 
|  1630  by the next COMMIT or ROLLBACK. |  | 
|  1631 } |  | 
|  1632  |  | 
|  1633 api {} { |  | 
|  1634   int sqlite3_clear_bindings(sqlite3_stmt*); |  | 
|  1635 } { |  | 
|  1636  Set all the parameters in the compiled SQL statement back to NULL. |  | 
|  1637 } |  | 
|  1638  |  | 
|  1639 api {} { |  | 
|  1640   sqlite3 *sqlite3_db_handle(sqlite3_stmt*); |  | 
|  1641 } { |  | 
|  1642  Return the sqlite3* database handle to which the prepared statement given |  | 
|  1643  in the argument belongs.  This is the same database handle that was |  | 
|  1644  the first argument to the sqlite3_prepare() that was used to create |  | 
|  1645  the statement in the first place. |  | 
|  1646 } |  | 
|  1647  |  | 
|  1648 api {} { |  | 
|  1649   void *sqlite3_update_hook( |  | 
|  1650     sqlite3*,  |  | 
|  1651     void(*)(void *,int ,char const *,char const *,sqlite_int64), |  | 
|  1652     void* |  | 
|  1653   ); |  | 
|  1654 } { |  | 
|  1655  Register a callback function with the database connection identified by the  |  | 
|  1656  first argument to be invoked whenever a row is updated, inserted or deleted. |  | 
|  1657  Any callback set by a previous call to this function for the same  |  | 
|  1658  database connection is overridden. |  | 
|  1659  |  | 
|  1660  The second argument is a pointer to the function to invoke when a  |  | 
|  1661  row is updated, inserted or deleted. The first argument to the callback is |  | 
|  1662  a copy of the third argument to sqlite3_update_hook. The second callback  |  | 
|  1663  argument is one of SQLITE_INSERT, SQLITE_DELETE or SQLITE_UPDATE, depending |  | 
|  1664  on the operation that caused the callback to be invoked. The third and  |  | 
|  1665  fourth arguments to the callback contain pointers to the database and  |  | 
|  1666  table name containing the affected row. The final callback parameter is  |  | 
|  1667  the rowid of the row. In the case of an update, this is the rowid after  |  | 
|  1668  the update takes place. |  | 
|  1669  |  | 
|  1670  The update hook is not invoked when internal system tables are |  | 
|  1671  modified (i.e. sqlite_master and sqlite_sequence). |  | 
|  1672  |  | 
|  1673  If another function was previously registered, its pArg value is returned. |  | 
|  1674  Otherwise NULL is returned. |  | 
|  1675  |  | 
|  1676  See also: sqlite3_commit_hook(), sqlite3_rollback_hook() |  | 
|  1677 } |  | 
|  1678  |  | 
|  1679 api {} { |  | 
|  1680   void *sqlite3_rollback_hook(sqlite3*, void(*)(void *), void*); |  | 
|  1681 } { |  | 
|  1682  Register a callback to be invoked whenever a transaction is rolled |  | 
|  1683  back.  |  | 
|  1684  |  | 
|  1685  The new callback function overrides any existing rollback-hook |  | 
|  1686  callback. If there was an existing callback, then it's pArg value  |  | 
|  1687  (the third argument to sqlite3_rollback_hook() when it was registered)  |  | 
|  1688  is returned. Otherwise, NULL is returned. |  | 
|  1689  |  | 
|  1690  For the purposes of this API, a transaction is said to have been  |  | 
|  1691  rolled back if an explicit "ROLLBACK" statement is executed, or |  | 
|  1692  an error or constraint causes an implicit rollback to occur. The  |  | 
|  1693  callback is not invoked if a transaction is automatically rolled |  | 
|  1694  back because the database connection is closed. |  | 
|  1695 } |  | 
|  1696  |  | 
|  1697 api {} { |  | 
|  1698   int sqlite3_enable_shared_cache(int); |  | 
|  1699 } { |  | 
|  1700   This routine enables or disables the sharing of the database cache |  | 
|  1701   and schema data structures between connections to the same database. |  | 
|  1702   Sharing is enabled if the argument is true and disabled if the argument |  | 
|  1703   is false. |  | 
|  1704  |  | 
|  1705   Cache sharing is enabled and disabled on a thread-by-thread basis. |  | 
|  1706   Each call to this routine enables or disables cache sharing only for |  | 
|  1707   connections created in the same thread in which this routine is called. |  | 
|  1708   There is no mechanism for sharing cache between database connections |  | 
|  1709   running in different threads. |  | 
|  1710  |  | 
|  1711   Sharing must be disabled prior to shutting down a thread or else |  | 
|  1712   the thread will leak memory.  Call this routine with an argument of |  | 
|  1713   0 to turn off sharing.  Or use the sqlite3_thread_cleanup() API. |  | 
|  1714  |  | 
|  1715   This routine must not be called when any database connections |  | 
|  1716   are active in the current thread.  Enabling or disabling shared |  | 
|  1717   cache while there are active database connections will result |  | 
|  1718   in memory corruption. |  | 
|  1719  |  | 
|  1720   When the shared cache is enabled, the |  | 
|  1721   following routines must always be called from the same thread: |  | 
|  1722   sqlite3_open(), sqlite3_prepare_v2(), sqlite3_step(), sqlite3_reset(), |  | 
|  1723   sqlite3_finalize(), and sqlite3_close(). |  | 
|  1724   This is due to the fact that the shared cache makes use of |  | 
|  1725   thread-specific storage so that it will be available for sharing |  | 
|  1726   with other connections. |  | 
|  1727  |  | 
|  1728   Virtual tables cannot be used with a shared cache.  When shared |  | 
|  1729   cache is enabled, the sqlite3_create_module() API used to register |  | 
|  1730   virtual tables will always return an error. |  | 
|  1731  |  | 
|  1732   This routine returns SQLITE_OK if shared cache was |  | 
|  1733   enabled or disabled successfully.  An error code is returned |  | 
|  1734   otherwise. |  | 
|  1735  |  | 
|  1736   Shared cache is disabled by default for backward compatibility. |  | 
|  1737 } |  | 
|  1738  |  | 
|  1739 api {} { |  | 
|  1740   void sqlite3_thread_cleanup(void); |  | 
|  1741 } { |  | 
|  1742   This routine makes sure that all thread local storage used by SQLite |  | 
|  1743   in the current thread has been deallocated.  A thread can call this |  | 
|  1744   routine prior to terminating in order to make sure there are no memory |  | 
|  1745   leaks. |  | 
|  1746  |  | 
|  1747   This routine is not strictly necessary.  If cache sharing has been |  | 
|  1748   disabled using sqlite3_enable_shared_cache() and if all database |  | 
|  1749   connections have been closed and if SQLITE_ENABLE_MEMORY_MANAGMENT is |  | 
|  1750   on and all memory has been freed, then the thread local storage will |  | 
|  1751   already have been automatically deallocated.  This routine is provided |  | 
|  1752   as a convenience to the program who just wants to make sure that there |  | 
|  1753   are no leaks. |  | 
|  1754 } |  | 
|  1755  |  | 
|  1756 api {} { |  | 
|  1757   int sqlite3_release_memory(int N); |  | 
|  1758 } { |  | 
|  1759   This routine attempts to free at least N bytes of memory from the caches |  | 
|  1760   of database connecions that were created in the same thread from which this |  | 
|  1761   routine is called.  The value returned is the number of bytes actually |  | 
|  1762   freed.   |  | 
|  1763  |  | 
|  1764   This routine is only available if memory management has been enabled |  | 
|  1765   by compiling with the SQLITE_ENABLE_MEMORY_MANAGMENT macro. |  | 
|  1766 } |  | 
|  1767  |  | 
|  1768 api {} { |  | 
|  1769   void sqlite3_soft_heap_limit(int N); |  | 
|  1770 } { |  | 
|  1771   This routine sets the soft heap limit for the current thread to N. |  | 
|  1772   If the total heap usage by SQLite in the current thread exceeds N, |  | 
|  1773   then sqlite3_release_memory() is called to try to reduce the memory usage |  | 
|  1774   below the soft limit. |  | 
|  1775  |  | 
|  1776   Prior to shutting down a thread sqlite3_soft_heap_limit() must be set to  |  | 
|  1777   zero (the default) or else the thread will leak memory. Alternatively, use |  | 
|  1778   the sqlite3_thread_cleanup() API. |  | 
|  1779  |  | 
|  1780   A negative or zero value for N means that there is no soft heap limit and |  | 
|  1781   sqlite3_release_memory() will only be called when memory is exhaused. |  | 
|  1782   The default value for the soft heap limit is zero. |  | 
|  1783  |  | 
|  1784   SQLite makes a best effort to honor the soft heap limit.  But if it |  | 
|  1785   is unable to reduce memory usage below the soft limit, execution will |  | 
|  1786   continue without error or notification.  This is why the limit is  |  | 
|  1787   called a "soft" limit.  It is advisory only. |  | 
|  1788  |  | 
|  1789   This routine is only available if memory management has been enabled |  | 
|  1790   by compiling with the SQLITE_ENABLE_MEMORY_MANAGMENT macro. |  | 
|  1791 } |  | 
|  1792  |  | 
|  1793 api {} { |  | 
|  1794   void sqlite3_thread_cleanup(void); |  | 
|  1795 } { |  | 
|  1796   This routine ensures that a thread that has used SQLite in the past |  | 
|  1797   has released any thread-local storage it might have allocated.   |  | 
|  1798   When the rest of the API is used properly, the cleanup of  |  | 
|  1799   thread-local storage should be completely automatic.  You should |  | 
|  1800   never really need to invoke this API.  But it is provided to you |  | 
|  1801   as a precaution and as a potential work-around for future |  | 
|  1802   thread-releated memory-leaks. |  | 
|  1803 } |  | 
|  1804  |  | 
|  1805 set n 0 |  | 
|  1806 set i 0 |  | 
|  1807 foreach item $apilist { |  | 
|  1808   set namelist [lindex $item 0] |  | 
|  1809   foreach name $namelist { |  | 
|  1810     set n_to_name($n) $name |  | 
|  1811     set n_to_idx($n) $i |  | 
|  1812     set name_to_idx($name) $i |  | 
|  1813     incr n |  | 
|  1814   } |  | 
|  1815   incr i |  | 
|  1816 } |  | 
|  1817 set i 0 |  | 
|  1818 foreach name [lsort [array names name_to_idx]] { |  | 
|  1819   set sname($i) $name |  | 
|  1820   incr i |  | 
|  1821 } |  | 
|  1822 #parray n_to_name |  | 
|  1823 #parray n_to_idx |  | 
|  1824 #parray name_to_idx |  | 
|  1825 #parray sname |  | 
|  1826 incr n -1 |  | 
|  1827 puts "<DIV class=pdf_ignore>" |  | 
|  1828 puts {<table width="100%" cellpadding="5"><tr>} |  | 
|  1829 set nrow [expr {($n+2)/3}] |  | 
|  1830 set i 0 |  | 
|  1831 for {set j 0} {$j<3} {incr j} { |  | 
|  1832   if {$j>0} {puts {<td width="10"></td>}} |  | 
|  1833   puts {<td valign="top">} |  | 
|  1834   set limit [expr {$i+$nrow}] |  | 
|  1835   puts {<ul>} |  | 
|  1836   while {$i<$limit && $i<$n} { |  | 
|  1837     set name $sname($i) |  | 
|  1838     if {[regexp {^sqlite} $name]} {set display $name} {set display <i>$name</i>} |  | 
|  1839     puts "<li><a href=\"#$name\">$display</a></li>" |  | 
|  1840     incr i |  | 
|  1841   } |  | 
|  1842   puts {</ul></td>} |  | 
|  1843 } |  | 
|  1844 puts "</table>" |  | 
|  1845 puts "<!-- $n entries.  $nrow rows in 3 columns -->" |  | 
|  1846 puts "</DIV>" |  | 
|  1847  |  | 
|  1848 proc resolve_name {ignore_list name} { |  | 
|  1849   global name_to_idx |  | 
|  1850   if {![info exists name_to_idx($name)] || [lsearch $ignore_list $name]>=0} { |  | 
|  1851     return $name |  | 
|  1852   } else { |  | 
|  1853     return "<a href=\"#$name\">$name</a>" |  | 
|  1854   } |  | 
|  1855 } |  | 
|  1856  |  | 
|  1857 foreach name [lsort [array names name_to_idx]] { |  | 
|  1858   set i $name_to_idx($name) |  | 
|  1859   if {[info exists done($i)]} continue |  | 
|  1860   set done($i) 1 |  | 
|  1861   foreach {namelist prototype desc} [lindex $apilist $i] break |  | 
|  1862   foreach name $namelist { |  | 
|  1863     puts "<a name=\"$name\"></a>" |  | 
|  1864   } |  | 
|  1865   puts "<p><hr></p>" |  | 
|  1866   puts "<blockquote><pre>" |  | 
|  1867   regsub "^( *\n)+" $prototype {} p2 |  | 
|  1868   regsub "(\n *)+\$" $p2 {} p3 |  | 
|  1869   puts $p3 |  | 
|  1870   puts "</pre></blockquote>" |  | 
|  1871   regsub -all {\[} $desc {\[} desc |  | 
|  1872   regsub -all {sqlite3_[a-z0-9_]+} $desc "\[resolve_name $name &\]" d2 |  | 
|  1873   foreach x $specialname { |  | 
|  1874     regsub -all $x $d2 "\[resolve_name $name &\]" d2 |  | 
|  1875   } |  | 
|  1876   regsub -all "\n( *\n)+" [subst $d2] "</p>\n\n<p>" d3 |  | 
|  1877   puts "<p>$d3</p>" |  | 
|  1878 } |  | 
|  1879  |  | 
|  1880 puts "<DIV class=pdf_ignore>" |  | 
|  1881 footer $rcsid |  | 
|  1882 puts "</DIV>" |  | 
| OLD | NEW |