| 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 |