| 1 |
/* |
|---|
| 2 |
** The D programming language |
|---|
| 3 |
** |
|---|
| 4 |
** Converted by Anders Bergh <anders1@gmail.com> |
|---|
| 5 |
** |
|---|
| 6 |
************************************************************************* |
|---|
| 7 |
** |
|---|
| 8 |
** 2001 September 15 |
|---|
| 9 |
** |
|---|
| 10 |
** The author disclaims copyright to this source code. In place of |
|---|
| 11 |
** a legal notice, here is a blessing: |
|---|
| 12 |
** |
|---|
| 13 |
** May you do good and not evil. |
|---|
| 14 |
** May you find forgiveness for yourself and forgive others. |
|---|
| 15 |
** May you share freely, never taking more than you give. |
|---|
| 16 |
** |
|---|
| 17 |
************************************************************************* |
|---|
| 18 |
** This header file defines the interface that the SQLite library |
|---|
| 19 |
** presents to client programs. If a C-function, structure, datatype, |
|---|
| 20 |
** or constant definition does not appear in this file, then it is |
|---|
| 21 |
** not a published API of SQLite, is subject to change without |
|---|
| 22 |
** notice, and should not be referenced by programs that use SQLite. |
|---|
| 23 |
** |
|---|
| 24 |
** Some of the definitions that are in this file are marked as |
|---|
| 25 |
** "experimental". Experimental interfaces are normally new |
|---|
| 26 |
** features recently added to SQLite. We do not anticipate changes |
|---|
| 27 |
** to experimental interfaces but reserve to make minor changes if |
|---|
| 28 |
** experience from use "in the wild" suggest such changes are prudent. |
|---|
| 29 |
** |
|---|
| 30 |
** The official C-language API documentation for SQLite is derived |
|---|
| 31 |
** from comments in this file. This file is the authoritative source |
|---|
| 32 |
** on how SQLite interfaces are suppose to operate. |
|---|
| 33 |
** |
|---|
| 34 |
** The name of this file under configuration management is "sqlite.h.in". |
|---|
| 35 |
** The makefile makes some minor changes to this file (such as inserting |
|---|
| 36 |
** the version number) and changes its name to "sqlite3.h" as |
|---|
| 37 |
** part of the build process. |
|---|
| 38 |
*/ |
|---|
| 39 |
|
|---|
| 40 |
module sqlite3; |
|---|
| 41 |
|
|---|
| 42 |
extern (C): |
|---|
| 43 |
|
|---|
| 44 |
// For va_list and int64_t, etc |
|---|
| 45 |
version (Tango) |
|---|
| 46 |
{ |
|---|
| 47 |
import tango.stdc.stdarg; |
|---|
| 48 |
import tango.stdc.inttypes; |
|---|
| 49 |
} |
|---|
| 50 |
else |
|---|
| 51 |
{ |
|---|
| 52 |
import std.c.stdarg; |
|---|
| 53 |
import std.stdint; |
|---|
| 54 |
} |
|---|
| 55 |
|
|---|
| 56 |
// Link with sqlite3 (rebuild) |
|---|
| 57 |
version (build) pragma(link, "sqlite3"); |
|---|
| 58 |
|
|---|
| 59 |
/* |
|---|
| 60 |
** CAPI3REF: Compile-Time Library Version Numbers |
|---|
| 61 |
** |
|---|
| 62 |
** The version of the SQLite library is contained in the sqlite3.h |
|---|
| 63 |
** header file in a #define named SQLITE_VERSION. The SQLITE_VERSION |
|---|
| 64 |
** macro resolves to a string constant. |
|---|
| 65 |
** |
|---|
| 66 |
** The format of the version string is "X.Y.Z", where |
|---|
| 67 |
** X is the major version number, Y is the minor version number and Z |
|---|
| 68 |
** is the release number. The X.Y.Z might be followed by "alpha" or "beta". |
|---|
| 69 |
** For example "3.1.1beta". |
|---|
| 70 |
** |
|---|
| 71 |
** The X value is always 3 in SQLite. The X value only changes when |
|---|
| 72 |
** backwards compatibility is broken and we intend to never break |
|---|
| 73 |
** backwards compatibility. The Y value only changes when |
|---|
| 74 |
** there are major feature enhancements that are forwards compatible |
|---|
| 75 |
** but not backwards compatible. The Z value is incremented with |
|---|
| 76 |
** each release but resets back to 0 when Y is incremented. |
|---|
| 77 |
** |
|---|
| 78 |
** The SQLITE_VERSION_NUMBER is an integer with the value |
|---|
| 79 |
** (X*1000000 + Y*1000 + Z). For example, for version "3.1.1beta", |
|---|
| 80 |
** SQLITE_VERSION_NUMBER is set to 3001001. To detect if they are using |
|---|
| 81 |
** version 3.1.1 or greater at compile time, programs may use the test |
|---|
| 82 |
** (SQLITE_VERSION_NUMBER>=3001001). |
|---|
| 83 |
** |
|---|
| 84 |
** See also: [sqlite3_libversion()] and [sqlite3_libversion_number()]. |
|---|
| 85 |
*/ |
|---|
| 86 |
const char[] SQLITE_VERSION = "3.5.1"; |
|---|
| 87 |
const SQLITE_VERSION_NUMBER = 3005001; |
|---|
| 88 |
|
|---|
| 89 |
/* |
|---|
| 90 |
** CAPI3REF: Run-Time Library Version Numbers |
|---|
| 91 |
** |
|---|
| 92 |
** These routines return values equivalent to the header constants |
|---|
| 93 |
** [SQLITE_VERSION] and [SQLITE_VERSION_NUMBER]. The values returned |
|---|
| 94 |
** by this routines should only be different from the header values |
|---|
| 95 |
** if you compile your program using an sqlite3.h header from a |
|---|
| 96 |
** different version of SQLite that the version of the library you |
|---|
| 97 |
** link against. |
|---|
| 98 |
** |
|---|
| 99 |
** The sqlite3_version[] string constant contains the text of the |
|---|
| 100 |
** [SQLITE_VERSION] string. The sqlite3_libversion() function returns |
|---|
| 101 |
** a poiner to the sqlite3_version[] string constant. The function |
|---|
| 102 |
** is provided for DLL users who can only access functions and not |
|---|
| 103 |
** constants within the DLL. |
|---|
| 104 |
*/ |
|---|
| 105 |
char* sqlite3_version; |
|---|
| 106 |
char* sqlite3_libversion(); |
|---|
| 107 |
int sqlite3_libversion_number(); |
|---|
| 108 |
|
|---|
| 109 |
/* |
|---|
| 110 |
** CAPI3REF: Test To See If The Library Is Threadsafe |
|---|
| 111 |
** |
|---|
| 112 |
** This routine returns TRUE (nonzero) if SQLite was compiled with |
|---|
| 113 |
** all of its mutexes enabled and is thus threadsafe. It returns |
|---|
| 114 |
** zero if the particular build is for single-threaded operation |
|---|
| 115 |
** only. |
|---|
| 116 |
** |
|---|
| 117 |
** Really all this routine does is return true if SQLite was compiled |
|---|
| 118 |
** with the -DSQLITE_THREADSAFE=1 option and false if |
|---|
| 119 |
** compiled with -DSQLITE_THREADSAFE=0. If SQLite uses an |
|---|
| 120 |
** application-defined mutex subsystem, malloc subsystem, collating |
|---|
| 121 |
** sequence, VFS, SQL function, progress callback, commit hook, |
|---|
| 122 |
** extension, or other accessories and these add-ons are not |
|---|
| 123 |
** threadsafe, then clearly the combination will not be threadsafe |
|---|
| 124 |
** either. Hence, this routine never reports that the library |
|---|
| 125 |
** is guaranteed to be threadsafe, only when it is guaranteed not |
|---|
| 126 |
** to be. |
|---|
| 127 |
** |
|---|
| 128 |
** This is an experimental API and may go away or change in future |
|---|
| 129 |
** releases. |
|---|
| 130 |
*/ |
|---|
| 131 |
int sqlite3_threadsafe(); |
|---|
| 132 |
|
|---|
| 133 |
/* |
|---|
| 134 |
** CAPI3REF: Database Connection Handle |
|---|
| 135 |
** |
|---|
| 136 |
** Each open SQLite database is represented by pointer to an instance of the |
|---|
| 137 |
** opaque structure named "sqlite3". It is useful to think of an sqlite3 |
|---|
| 138 |
** pointer as an object. The [sqlite3_open()], [sqlite3_open16()], and |
|---|
| 139 |
** [sqlite3_open_v2()] interfaces are its constructors |
|---|
| 140 |
** and [sqlite3_close()] is its destructor. There are many other interfaces |
|---|
| 141 |
** (such as [sqlite3_prepare_v2()], [sqlite3_create_function()], and |
|---|
| 142 |
** [sqlite3_busy_timeout()] to name but three) that are methods on this |
|---|
| 143 |
** object. |
|---|
| 144 |
*/ |
|---|
| 145 |
struct sqlite3; |
|---|
| 146 |
|
|---|
| 147 |
|
|---|
| 148 |
/* |
|---|
| 149 |
** CAPI3REF: 64-Bit Integer Types |
|---|
| 150 |
** |
|---|
| 151 |
** Some compilers do not support the "long long" datatype. So we have |
|---|
| 152 |
** to do compiler-specific typedefs for 64-bit signed and unsigned integers. |
|---|
| 153 |
** |
|---|
| 154 |
** Many SQLite interface functions require a 64-bit integer arguments. |
|---|
| 155 |
** Those interfaces are declared using this typedef. |
|---|
| 156 |
*/ |
|---|
| 157 |
alias int64_t sqlite3_int64; |
|---|
| 158 |
alias uint64_t sqlite3_uint64; |
|---|
| 159 |
|
|---|
| 160 |
/* |
|---|
| 161 |
** CAPI3REF: Closing A Database Connection |
|---|
| 162 |
** |
|---|
| 163 |
** Call this function with a pointer to a structure that was previously |
|---|
| 164 |
** returned from [sqlite3_open()], [sqlite3_open16()], or |
|---|
| 165 |
** [sqlite3_open_v2()] and the corresponding database will by |
|---|
| 166 |
** closed. |
|---|
| 167 |
** |
|---|
| 168 |
** All SQL statements prepared using [sqlite3_prepare_v2()] or |
|---|
| 169 |
** [sqlite3_prepare16_v2()] must be destroyed using [sqlite3_finalize()] |
|---|
| 170 |
** before this routine is called. Otherwise, SQLITE_BUSY is returned and the |
|---|
| 171 |
** database connection remains open. |
|---|
| 172 |
** |
|---|
| 173 |
** Passing this routine a database connection that has already been |
|---|
| 174 |
** closed results in undefined behavior. If other interfaces that |
|---|
| 175 |
** reference the same database connection are pending (either in the |
|---|
| 176 |
** same thread or in different threads) when this routine is called, |
|---|
| 177 |
** then the behavior is undefined and is almost certainly undesirable. |
|---|
| 178 |
*/ |
|---|
| 179 |
int sqlite3_close(sqlite3 *); |
|---|
| 180 |
|
|---|
| 181 |
/* |
|---|
| 182 |
** The type for a callback function. |
|---|
| 183 |
** This is legacy and deprecated. It is included for historical |
|---|
| 184 |
** compatibility and is not documented. |
|---|
| 185 |
*/ |
|---|
| 186 |
alias int function(void*,int,char**, char**) sqlite3_callback; |
|---|
| 187 |
|
|---|
| 188 |
/* |
|---|
| 189 |
** CAPI3REF: One-Step Query Execution Interface |
|---|
| 190 |
** |
|---|
| 191 |
** This interface is used to do a one-time evaluatation of zero |
|---|
| 192 |
** or more SQL statements. UTF-8 text of the SQL statements to |
|---|
| 193 |
** be evaluted is passed in as the second parameter. The statements |
|---|
| 194 |
** are prepared one by one using [sqlite3_prepare()], evaluated |
|---|
| 195 |
** using [sqlite3_step()], then destroyed using [sqlite3_finalize()]. |
|---|
| 196 |
** |
|---|
| 197 |
** If one or more of the SQL statements are queries, then |
|---|
| 198 |
** the callback function specified by the 3rd parameter is |
|---|
| 199 |
** invoked once for each row of the query result. This callback |
|---|
| 200 |
** should normally return 0. If the callback returns a non-zero |
|---|
| 201 |
** value then the query is aborted, all subsequent SQL statements |
|---|
| 202 |
** are skipped and the sqlite3_exec() function returns the [SQLITE_ABORT]. |
|---|
| 203 |
** |
|---|
| 204 |
** The 4th parameter to this interface is an arbitrary pointer that is |
|---|
| 205 |
** passed through to the callback function as its first parameter. |
|---|
| 206 |
** |
|---|
| 207 |
** The 2nd parameter to the callback function is the number of |
|---|
| 208 |
** columns in the query result. The 3rd parameter to the callback |
|---|
| 209 |
** is an array of strings holding the values for each column |
|---|
| 210 |
** as extracted using [sqlite3_column_text()]. |
|---|
| 211 |
** The 4th parameter to the callback is an array of strings |
|---|
| 212 |
** obtained using [sqlite3_column_name()] and holding |
|---|
| 213 |
** the names of each column. |
|---|
| 214 |
** |
|---|
| 215 |
** The callback function may be NULL, even for queries. A NULL |
|---|
| 216 |
** callback is not an error. It just means that no callback |
|---|
| 217 |
** will be invoked. |
|---|
| 218 |
** |
|---|
| 219 |
** If an error occurs while parsing or evaluating the SQL (but |
|---|
| 220 |
** not while executing the callback) then an appropriate error |
|---|
| 221 |
** message is written into memory obtained from [sqlite3_malloc()] and |
|---|
| 222 |
** *errmsg is made to point to that message. The calling function |
|---|
| 223 |
** is responsible for freeing the memory using [sqlite3_free()]. |
|---|
| 224 |
** If errmsg==NULL, then no error message is ever written. |
|---|
| 225 |
** |
|---|
| 226 |
** The return value is is SQLITE_OK if there are no errors and |
|---|
| 227 |
** some other [SQLITE_OK | return code] if there is an error. |
|---|
| 228 |
** The particular return value depends on the type of error. |
|---|
| 229 |
** |
|---|
| 230 |
*/ |
|---|
| 231 |
int sqlite3_exec( |
|---|
| 232 |
sqlite3*, /* An open database */ |
|---|
| 233 |
char *sql, /* SQL to be evaluted */ |
|---|
| 234 |
int function(void*,int,char**,char**) callback, /* Callback function */ |
|---|
| 235 |
void *, /* 1st argument to callback */ |
|---|
| 236 |
char **errmsg /* Error msg written here */ |
|---|
| 237 |
); |
|---|
| 238 |
|
|---|
| 239 |
/* |
|---|
| 240 |
** CAPI3REF: Result Codes |
|---|
| 241 |
** KEYWORDS: SQLITE_OK |
|---|
| 242 |
** |
|---|
| 243 |
** Many SQLite functions return an integer result code from the set shown |
|---|
| 244 |
** above in order to indicates success or failure. |
|---|
| 245 |
** |
|---|
| 246 |
** The result codes above are the only ones returned by SQLite in its |
|---|
| 247 |
** default configuration. However, the [sqlite3_extended_result_codes()] |
|---|
| 248 |
** API can be used to set a database connectoin to return more detailed |
|---|
| 249 |
** result codes. |
|---|
| 250 |
** |
|---|
| 251 |
** See also: [SQLITE_IOERR_READ | extended result codes] |
|---|
| 252 |
** |
|---|
| 253 |
*/ |
|---|
| 254 |
const SQLITE_OK = 0; /* Successful result */ |
|---|
| 255 |
/* beginning-of-error-codes */ |
|---|
| 256 |
const SQLITE_ERROR = 1; /* SQL error or missing database */ |
|---|
| 257 |
const SQLITE_INTERNAL = 2; /* NOT USED. Internal logic error in SQLite */ |
|---|
| 258 |
const SQLITE_PERM = 3; /* Access permission denied */ |
|---|
| 259 |
const SQLITE_ABORT = 4; /* Callback routine requested an abort */ |
|---|
| 260 |
const SQLITE_BUSY = 5; /* The database file is locked */ |
|---|
| 261 |
const SQLITE_LOCKED = 6; /* A table in the database is locked */ |
|---|
| 262 |
const SQLITE_NOMEM = 7; /* A malloc() failed */ |
|---|
| 263 |
const SQLITE_READONLY = 8; /* Attempt to write a readonly database */ |
|---|
| 264 |
const SQLITE_INTERRUPT = 9; /* Operation terminated by sqlite3_interrupt()*/ |
|---|
| 265 |
const SQLITE_IOERR = 10; /* Some kind of disk I/O error occurred */ |
|---|
| 266 |
const SQLITE_CORRUPT = 11; /* The database disk image is malformed */ |
|---|
| 267 |
const SQLITE_NOTFOUND = 12; /* NOT USED. Table or record not found */ |
|---|
| 268 |
const SQLITE_FULL = 13; /* Insertion failed because database is full */ |
|---|
| 269 |
const SQLITE_CANTOPEN = 14; /* Unable to open the database file */ |
|---|
| 270 |
const SQLITE_PROTOCOL = 15; /* NOT USED. Database lock protocol error */ |
|---|
| 271 |
const SQLITE_EMPTY = 16; /* Database is empty */ |
|---|
| 272 |
const SQLITE_SCHEMA = 17; /* The database schema changed */ |
|---|
| 273 |
const SQLITE_TOOBIG = 18; /* String or BLOB exceeds size limit */ |
|---|
| 274 |
const SQLITE_CONSTRAINT = 19; /* Abort due to constraint violation */ |
|---|
| 275 |
const SQLITE_MISMATCH = 20; /* Data type mismatch */ |
|---|
| 276 |
const SQLITE_MISUSE = 21; /* Library used incorrectly */ |
|---|
| 277 |
const SQLITE_NOLFS = 22; /* Uses OS features not supported on host */ |
|---|
| 278 |
const SQLITE_AUTH = 23; /* Authorization denied */ |
|---|
| 279 |
const SQLITE_FORMAT = 24; /* Auxiliary database format error */ |
|---|
| 280 |
const SQLITE_RANGE = 25; /* 2nd parameter to sqlite3_bind out of range */ |
|---|
| 281 |
const SQLITE_NOTADB = 26; /* File opened that is not a database file */ |
|---|
| 282 |
const SQLITE_ROW = 100; /* sqlite3_step() has another row ready */ |
|---|
| 283 |
const SQLITE_DONE = 101; /* sqlite3_step() has finished executing */ |
|---|
| 284 |
/* end-of-error-codes */ |
|---|
| 285 |
|
|---|
| 286 |
/* |
|---|
| 287 |
** CAPI3REF: Extended Result Codes |
|---|
| 288 |
** |
|---|
| 289 |
** In its default configuration, SQLite API routines return one of 26 integer |
|---|
| 290 |
** result codes described at result-codes. However, experience has shown that |
|---|
| 291 |
** many of these result codes are too course-grained. They do not provide as |
|---|
| 292 |
** much information about problems as users might like. In an effort to |
|---|
| 293 |
** address this, newer versions of SQLite (version 3.3.8 and later) include |
|---|
| 294 |
** support for additional result codes that provide more detailed information |
|---|
| 295 |
** about errors. The extended result codes are enabled (or disabled) for |
|---|
| 296 |
** each database |
|---|
| 297 |
** connection using the [sqlite3_extended_result_codes()] API. |
|---|
| 298 |
** |
|---|
| 299 |
** Some of the available extended result codes are listed above. |
|---|
| 300 |
** We expect the number of extended result codes will be expand |
|---|
| 301 |
** over time. Software that uses extended result codes should expect |
|---|
| 302 |
** to see new result codes in future releases of SQLite. |
|---|
| 303 |
** |
|---|
| 304 |
** The symbolic name for an extended result code always contains a related |
|---|
| 305 |
** primary result code as a prefix. Primary result codes contain a single |
|---|
| 306 |
** "_" character. Extended result codes contain two or more "_" characters. |
|---|
| 307 |
** The numeric value of an extended result code can be converted to its |
|---|
| 308 |
** corresponding primary result code by masking off the lower 8 bytes. |
|---|
| 309 |
** |
|---|
| 310 |
** The SQLITE_OK result code will never be extended. It will always |
|---|
| 311 |
** be exactly zero. |
|---|
| 312 |
*/ |
|---|
| 313 |
const SQLITE_IOERR_READ = (SQLITE_IOERR | (1<<8)); |
|---|
| 314 |
const SQLITE_IOERR_SHORT_READ = (SQLITE_IOERR | (2<<8)); |
|---|
| 315 |
const SQLITE_IOERR_WRITE = (SQLITE_IOERR | (3<<8)); |
|---|
| 316 |
const SQLITE_IOERR_FSYNC = (SQLITE_IOERR | (4<<8)); |
|---|
| 317 |
const SQLITE_IOERR_DIR_FSYNC = (SQLITE_IOERR | (5<<8)); |
|---|
| 318 |
const SQLITE_IOERR_TRUNCATE = (SQLITE_IOERR | (6<<8)); |
|---|
| 319 |
const SQLITE_IOERR_FSTAT = (SQLITE_IOERR | (7<<8)); |
|---|
| 320 |
const SQLITE_IOERR_UNLOCK = (SQLITE_IOERR | (8<<8)); |
|---|
| 321 |
const SQLITE_IOERR_RDLOCK = (SQLITE_IOERR | (9<<8)); |
|---|
| 322 |
const SQLITE_IOERR_DELETE = (SQLITE_IOERR | (10<<8)); |
|---|
| 323 |
const SQLITE_IOERR_BLOCKED = (SQLITE_IOERR | (11<<8)); |
|---|
| 324 |
const SQLITE_IOERR_NOMEM = (SQLITE_IOERR | (12<<8)); |
|---|
| 325 |
|
|---|
| 326 |
/* |
|---|
| 327 |
** CAPI3REF: Flags For File Open Operations |
|---|
| 328 |
** |
|---|
| 329 |
** Combination of the following bit values are used as the |
|---|
| 330 |
** third argument to the [sqlite3_open_v2()] interface and |
|---|
| 331 |
** as fourth argument to the xOpen method of the |
|---|
| 332 |
** [sqlite3_vfs] object. |
|---|
| 333 |
** |
|---|
| 334 |
*/ |
|---|
| 335 |
const SQLITE_OPEN_READONLY = 0x00000001; |
|---|
| 336 |
const SQLITE_OPEN_READWRITE = 0x00000002; |
|---|
| 337 |
const SQLITE_OPEN_CREATE = 0x00000004; |
|---|
| 338 |
const SQLITE_OPEN_DELETEONCLOSE = 0x00000008; |
|---|
| 339 |
const SQLITE_OPEN_EXCLUSIVE = 0x00000010; |
|---|
| 340 |
const SQLITE_OPEN_MAIN_DB = 0x00000100; |
|---|
| 341 |
const SQLITE_OPEN_TEMP_DB = 0x00000200; |
|---|
| 342 |
const SQLITE_OPEN_TRANSIENT_DB = 0x00000400; |
|---|
| 343 |
const SQLITE_OPEN_MAIN_JOURNAL = 0x00000800; |
|---|
| 344 |
const SQLITE_OPEN_TEMP_JOURNAL = 0x00001000; |
|---|
| 345 |
const SQLITE_OPEN_SUBJOURNAL = 0x00002000; |
|---|
| 346 |
const SQLITE_OPEN_MASTER_JOURNAL = 0x00004000; |
|---|
| 347 |
|
|---|
| 348 |
/* |
|---|
| 349 |
** CAPI3REF: Device Characteristics |
|---|
| 350 |
** |
|---|
| 351 |
** The xDeviceCapabilities method of the [sqlite3_io_methods] |
|---|
| 352 |
** object returns an integer which is a vector of the following |
|---|
| 353 |
** bit values expressing I/O characteristics of the mass storage |
|---|
| 354 |
** device that holds the file that the [sqlite3_io_methods] |
|---|
| 355 |
** refers to. |
|---|
| 356 |
** |
|---|
| 357 |
** The SQLITE_IOCAP_ATOMIC property means that all writes of |
|---|
| 358 |
** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values |
|---|
| 359 |
** mean that writes of blocks that are nnn bytes in size and |
|---|
| 360 |
** are aligned to an address which is an integer multiple of |
|---|
| 361 |
** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means |
|---|
| 362 |
** that when data is appended to a file, the data is appended |
|---|
| 363 |
** first then the size of the file is extended, never the other |
|---|
| 364 |
** way around. The SQLITE_IOCAP_SEQUENTIAL property means that |
|---|
| 365 |
** information is written to disk in the same order as calls |
|---|
| 366 |
** to xWrite(). |
|---|
| 367 |
*/ |
|---|
| 368 |
const SQLITE_IOCAP_ATOMIC = 0x00000001; |
|---|
| 369 |
const SQLITE_IOCAP_ATOMIC512 = 0x00000002; |
|---|
| 370 |
const SQLITE_IOCAP_ATOMIC1K = 0x00000004; |
|---|
| 371 |
const SQLITE_IOCAP_ATOMIC2K = 0x00000008; |
|---|
| 372 |
const SQLITE_IOCAP_ATOMIC4K = 0x00000010; |
|---|
| 373 |
const SQLITE_IOCAP_ATOMIC8K = 0x00000020; |
|---|
| 374 |
const SQLITE_IOCAP_ATOMIC16K = 0x00000040; |
|---|
| 375 |
const SQLITE_IOCAP_ATOMIC32K = 0x00000080; |
|---|
| 376 |
const SQLITE_IOCAP_ATOMIC64K = 0x00000100; |
|---|
| 377 |
const SQLITE_IOCAP_SAFE_APPEND = 0x00000200; |
|---|
| 378 |
const SQLITE_IOCAP_SEQUENTIAL = 0x00000400; |
|---|
| 379 |
|
|---|
| 380 |
/* |
|---|
| 381 |
** CAPI3REF: File Locking Levels |
|---|
| 382 |
** |
|---|
| 383 |
** SQLite uses one of the following integer values as the second |
|---|
| 384 |
** argument to calls it makes to the xLock() and xUnlock() methods |
|---|
| 385 |
** of an [sqlite3_io_methods] object. |
|---|
| 386 |
*/ |
|---|
| 387 |
const SQLITE_LOCK_NONE = 0; |
|---|
| 388 |
const SQLITE_LOCK_SHARED = 1; |
|---|
| 389 |
const SQLITE_LOCK_RESERVED = 2; |
|---|
| 390 |
const SQLITE_LOCK_PENDING = 3; |
|---|
| 391 |
const SQLITE_LOCK_EXCLUSIVE = 4; |
|---|
| 392 |
|
|---|
| 393 |
/* |
|---|
| 394 |
** CAPI3REF: Synchronization Type Flags |
|---|
| 395 |
** |
|---|
| 396 |
** When SQLite invokes the xSync() method of an [sqlite3_io_methods] |
|---|
| 397 |
** object it uses a combination of the following integer values as |
|---|
| 398 |
** the second argument. |
|---|
| 399 |
** |
|---|
| 400 |
** When the SQLITE_SYNC_DATAONLY flag is used, it means that the |
|---|
| 401 |
** sync operation only needs to flush data to mass storage. Inode |
|---|
| 402 |
** information need not be flushed. The SQLITE_SYNC_NORMAL means |
|---|
| 403 |
** to use normal fsync() semantics. The SQLITE_SYNC_FULL flag means |
|---|
| 404 |
** to use Mac OS-X style fullsync instead of fsync(). |
|---|
| 405 |
*/ |
|---|
| 406 |
const SQLITE_SYNC_NORMAL = 0x00002; |
|---|
| 407 |
const SQLITE_SYNC_FULL = 0x00003; |
|---|
| 408 |
const SQLITE_SYNC_DATAONLY = 0x00010; |
|---|
| 409 |
|
|---|
| 410 |
|
|---|
| 411 |
/* |
|---|
| 412 |
** CAPI3REF: OS Interface Open File Handle |
|---|
| 413 |
** |
|---|
| 414 |
** An [sqlite3_file] object represents an open file in the OS |
|---|
| 415 |
** interface layer. Individual OS interface implementations will |
|---|
| 416 |
** want to subclass this object by appending additional fields |
|---|
| 417 |
** for their own use. The pMethods entry is a pointer to an |
|---|
| 418 |
** [sqlite3_io_methods] object that defines methods for performing |
|---|
| 419 |
** I/O operations on the open file. |
|---|
| 420 |
*/ |
|---|
| 421 |
struct sqlite3_file { |
|---|
| 422 |
sqlite3_io_methods* pMethods; |
|---|
| 423 |
} |
|---|
| 424 |
|
|---|
| 425 |
/* |
|---|
| 426 |
** CAPI3REF: OS Interface File Virtual Methods Object |
|---|
| 427 |
** |
|---|
| 428 |
** Every file opened by the [sqlite3_vfs] xOpen method contains a pointer to |
|---|
| 429 |
** an instance of the this object. This object defines the |
|---|
| 430 |
** methods used to perform various operations against the open file. |
|---|
| 431 |
** |
|---|
| 432 |
** The flags argument to xSync may be one of [SQLITE_SYNC_NORMAL] or |
|---|
| 433 |
** [SQLITE_SYNC_FULL]. The first choice is the normal fsync(). |
|---|
| 434 |
* The second choice is an |
|---|
| 435 |
** OS-X style fullsync. The SQLITE_SYNC_DATA flag may be ORed in to |
|---|
| 436 |
** indicate that only the data of the file and not its inode needs to be |
|---|
| 437 |
** synced. |
|---|
| 438 |
** |
|---|
| 439 |
** The integer values to xLock() and xUnlock() are one of |
|---|
| 440 |
** <ul> |
|---|
| 441 |
** <li> [SQLITE_LOCK_NONE], |
|---|
| 442 |
** <li> [SQLITE_LOCK_SHARED], |
|---|
| 443 |
** <li> [SQLITE_LOCK_RESERVED], |
|---|
| 444 |
** <li> [SQLITE_LOCK_PENDING], or |
|---|
| 445 |
** <li> [SQLITE_LOCK_EXCLUSIVE]. |
|---|
| 446 |
** </ul> |
|---|
| 447 |
** xLock() increases the lock. xUnlock() decreases the lock. |
|---|
| 448 |
** The xCheckReservedLock() method looks |
|---|
| 449 |
** to see if any database connection, either in this |
|---|
| 450 |
** process or in some other process, is holding an RESERVED, |
|---|
| 451 |
** PENDING, or EXCLUSIVE lock on the file. It returns true |
|---|
| 452 |
** if such a lock exists and false if not. |
|---|
| 453 |
** |
|---|
| 454 |
** The xFileControl() method is a generic interface that allows custom |
|---|
| 455 |
** VFS implementations to directly control an open file using the |
|---|
| 456 |
** [sqlite3_file_control()] interface. The second "op" argument |
|---|
| 457 |
** is an integer opcode. The third |
|---|
| 458 |
** argument is a generic pointer which is intended to be a pointer |
|---|
| 459 |
** to a structure that may contain arguments or space in which to |
|---|
| 460 |
** write return values. Potential uses for xFileControl() might be |
|---|
| 461 |
** functions to enable blocking locks with timeouts, to change the |
|---|
| 462 |
** locking strategy (for example to use dot-file locks), to inquire |
|---|
| 463 |
** about the status of a lock, or to break stale locks. The SQLite |
|---|
| 464 |
** core reserves opcodes less than 100 for its own use. |
|---|
| 465 |
** A [SQLITE_FCNTL_LOCKSTATE | list of opcodes] less than 100 is available. |
|---|
| 466 |
** Applications that define a custom xFileControl method should use opcodes |
|---|
| 467 |
** greater than 100 to avoid conflicts. |
|---|
| 468 |
** |
|---|
| 469 |
** The xSectorSize() method returns the sector size of the |
|---|
| 470 |
** device that underlies the file. The sector size is the |
|---|
| 471 |
** minimum write that can be performed without disturbing |
|---|
| 472 |
** other bytes in the file. The xDeviceCharacteristics() |
|---|
| 473 |
** method returns a bit vector describing behaviors of the |
|---|
| 474 |
** underlying device: |
|---|
| 475 |
** |
|---|
| 476 |
** <ul> |
|---|
| 477 |
** <li> [SQLITE_IOCAP_ATOMIC] |
|---|
| 478 |
** <li> [SQLITE_IOCAP_ATOMIC512] |
|---|
| 479 |
** <li> [SQLITE_IOCAP_ATOMIC1K] |
|---|
| 480 |
** <li> [SQLITE_IOCAP_ATOMIC2K] |
|---|
| 481 |
** <li> [SQLITE_IOCAP_ATOMIC4K] |
|---|
| 482 |
** <li> [SQLITE_IOCAP_ATOMIC8K] |
|---|
| 483 |
** <li> [SQLITE_IOCAP_ATOMIC16K] |
|---|
| 484 |
** <li> [SQLITE_IOCAP_ATOMIC32K] |
|---|
| 485 |
** <li> [SQLITE_IOCAP_ATOMIC64K] |
|---|
| 486 |
** <li> [SQLITE_IOCAP_SAFE_APPEND] |
|---|
| 487 |
** <li> [SQLITE_IOCAP_SEQUENTIAL] |
|---|
| 488 |
** </ul> |
|---|
| 489 |
** |
|---|
| 490 |
** The SQLITE_IOCAP_ATOMIC property means that all writes of |
|---|
| 491 |
** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values |
|---|
| 492 |
** mean that writes of blocks that are nnn bytes in size and |
|---|
| 493 |
** are aligned to an address which is an integer multiple of |
|---|
| 494 |
** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means |
|---|
| 495 |
** that when data is appended to a file, the data is appended |
|---|
| 496 |
** first then the size of the file is extended, never the other |
|---|
| 497 |
** way around. The SQLITE_IOCAP_SEQUENTIAL property means that |
|---|
| 498 |
** information is written to disk in the same order as calls |
|---|
| 499 |
** to xWrite(). |
|---|
| 500 |
*/ |
|---|
| 501 |
struct sqlite3_io_methods { |
|---|
| 502 |
int iVersion; |
|---|
| 503 |
int function(sqlite3_file*) xClose; |
|---|
| 504 |
int function(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst) xRead; |
|---|
| 505 |
int function(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst) xWrite; |
|---|
| 506 |
int function(sqlite3_file*, sqlite3_int64 size) xTruncate; |
|---|
| 507 |
int function(sqlite3_file*, int flags) xSync; |
|---|
| 508 |
int function(sqlite3_file*, sqlite3_int64 *pSize) xFileSize; |
|---|
| 509 |
int function(sqlite3_file*, int) xLock; |
|---|
| 510 |
int function(sqlite3_file*, int) xUnlock; |
|---|
| 511 |
int function(sqlite3_file*) xCheckReservedLock; |
|---|
| 512 |
int function(sqlite3_file*, int op, void* pArg) xFileControl; |
|---|
| 513 |
int function(sqlite3_file*) xSectorSize; |
|---|
| 514 |
int function(sqlite3_file*) xDeviceCharacteristics; |
|---|
| 515 |
/* Additional methods may be added in future releases */ |
|---|
| 516 |
} |
|---|
| 517 |
|
|---|
| 518 |
/* |
|---|
| 519 |
** CAPI3REF: Standard File Control Opcodes |
|---|
| 520 |
** |
|---|
| 521 |
** These integer constants are opcodes for the xFileControl method |
|---|
| 522 |
** of the [sqlite3_io_methods] object and to the [sqlite3_file_control()] |
|---|
| 523 |
** interface. |
|---|
| 524 |
** |
|---|
| 525 |
** The [SQLITE_FCNTL_LOCKSTATE] opcode is used for debugging. This |
|---|
| 526 |
** opcode cases the xFileControl method to write the current state of |
|---|
| 527 |
** the lock (one of [SQLITE_LOCK_NONE], [SQLITE_LOCK_SHARED], |
|---|
| 528 |
** [SQLITE_LOCK_RESERVED], [SQLITE_LOCK_PENDING], or [SQLITE_LOCK_EXCLUSIVE]) |
|---|
| 529 |
** into an integer that the pArg argument points to. This capability |
|---|
| 530 |
** is used during testing and only needs to be supported when SQLITE_TEST |
|---|
| 531 |
** is defined. |
|---|
| 532 |
*/ |
|---|
| 533 |
const SQLITE_FCNTL_LOCKSTATE = 1; |
|---|
| 534 |
|
|---|
| 535 |
/* |
|---|
| 536 |
** CAPI3REF: Mutex Handle |
|---|
| 537 |
** |
|---|
| 538 |
** The mutex module within SQLite defines [sqlite3_mutex] to be an |
|---|
| 539 |
** abstract type for a mutex object. The SQLite core never looks |
|---|
| 540 |
** at the internal representation of an [sqlite3_mutex]. It only |
|---|
| 541 |
** deals with pointers to the [sqlite3_mutex] object. |
|---|
| 542 |
** |
|---|
| 543 |
** Mutexes are created using [sqlite3_mutex_alloc()]. |
|---|
| 544 |
*/ |
|---|
| 545 |
struct sqlite3_mutex; |
|---|
| 546 |
|
|---|
| 547 |
/* |
|---|
| 548 |
** CAPI3REF: OS Interface Object |
|---|
| 549 |
** |
|---|
| 550 |
** An instance of this object defines the interface between the |
|---|
| 551 |
** SQLite core and the underlying operating system. The "vfs" |
|---|
| 552 |
** in the name of the object stands for "virtual file system". |
|---|
| 553 |
** |
|---|
| 554 |
** The iVersion field is initially 1 but may be larger for future |
|---|
| 555 |
** versions of SQLite. Additional fields may be appended to this |
|---|
| 556 |
** object when the iVersion value is increased. |
|---|
| 557 |
** |
|---|
| 558 |
** The szOsFile field is the size of the subclassed [sqlite3_file] |
|---|
| 559 |
** structure used by this VFS. mxPathname is the maximum length of |
|---|
| 560 |
** a pathname in this VFS. |
|---|
| 561 |
** |
|---|
| 562 |
** Registered vfs modules are kept on a linked list formed by |
|---|
| 563 |
** the pNext pointer. The [sqlite3_vfs_register()] |
|---|
| 564 |
** and [sqlite3_vfs_unregister()] interfaces manage this list |
|---|
| 565 |
** in a thread-safe way. The [sqlite3_vfs_find()] interface |
|---|
| 566 |
** searches the list. |
|---|
| 567 |
** |
|---|
| 568 |
** The pNext field is the only fields in the sqlite3_vfs |
|---|
| 569 |
** structure that SQLite will ever modify. SQLite will only access |
|---|
| 570 |
** or modify this field while holding a particular static mutex. |
|---|
| 571 |
** The application should never modify anything within the sqlite3_vfs |
|---|
| 572 |
** object once the object has been registered. |
|---|
| 573 |
** |
|---|
| 574 |
** The zName field holds the name of the VFS module. The name must |
|---|
| 575 |
** be unique across all VFS modules. |
|---|
| 576 |
** |
|---|
| 577 |
** SQLite will guarantee that the zFilename string passed to |
|---|
| 578 |
** xOpen() is a full pathname as generated by xFullPathname() and |
|---|
| 579 |
** that the string will be valid and unchanged until xClose() is |
|---|
| 580 |
** called. So the [sqlite3_file] can store a pointer to the |
|---|
| 581 |
** filename if it needs to remember the filename for some reason. |
|---|
| 582 |
** |
|---|
| 583 |
** The flags argument to xOpen() is a copy of the flags argument |
|---|
| 584 |
** to [sqlite3_open_v2()]. If [sqlite3_open()] or [sqlite3_open16()] |
|---|
| 585 |
** is used, then flags is [SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE]. |
|---|
| 586 |
** If xOpen() opens a file read-only then it sets *pOutFlags to |
|---|
| 587 |
** include [SQLITE_OPEN_READONLY]. Other bits in *pOutFlags may be |
|---|
| 588 |
** set. |
|---|
| 589 |
** |
|---|
| 590 |
** SQLite will also add one of the following flags to the xOpen() |
|---|
| 591 |
** call, depending on the object being opened: |
|---|
| 592 |
** |
|---|
| 593 |
** <ul> |
|---|
| 594 |
** <li> [SQLITE_OPEN_MAIN_DB] |
|---|
| 595 |
** <li> [SQLITE_OPEN_MAIN_JOURNAL] |
|---|
| 596 |
** <li> [SQLITE_OPEN_TEMP_DB] |
|---|
| 597 |
** <li> [SQLITE_OPEN_TEMP_JOURNAL] |
|---|
| 598 |
** <li> [SQLITE_OPEN_TRANSIENT_DB] |
|---|
| 599 |
** <li> [SQLITE_OPEN_SUBJOURNAL] |
|---|
| 600 |
** <li> [SQLITE_OPEN_MASTER_JOURNAL] |
|---|
| 601 |
** </ul> |
|---|
| 602 |
** |
|---|
| 603 |
** The file I/O implementation can use the object type flags to |
|---|
| 604 |
** changes the way it deals with files. For example, an application |
|---|
| 605 |
** that does not care about crash recovery or rollback, might make |
|---|
| 606 |
** the open of a journal file a no-op. Writes to this journal are |
|---|
| 607 |
** also a no-op. Any attempt to read the journal return SQLITE_IOERR. |
|---|
| 608 |
** Or the implementation might recognize the a database file will |
|---|
| 609 |
** be doing page-aligned sector reads and writes in a random order |
|---|
| 610 |
** and set up its I/O subsystem accordingly. |
|---|
| 611 |
** |
|---|
| 612 |
** SQLite might also add one of the following flags to the xOpen |
|---|
| 613 |
** method: |
|---|
| 614 |
** |
|---|
| 615 |
** <ul> |
|---|
| 616 |
** <li> [SQLITE_OPEN_DELETEONCLOSE] |
|---|
| 617 |
** <li> [SQLITE_OPEN_EXCLUSIVE] |
|---|
| 618 |
** </ul> |
|---|
| 619 |
** |
|---|
| 620 |
** The [SQLITE_OPEN_DELETEONCLOSE] flag means the file should be |
|---|
| 621 |
** deleted when it is closed. This will always be set for TEMP |
|---|
| 622 |
** databases and journals and for subjournals. The |
|---|
| 623 |
** [SQLITE_OPEN_EXCLUSIVE] flag means the file should be opened |
|---|
| 624 |
** for exclusive access. This flag is set for all files except |
|---|
| 625 |
** for the main database file. |
|---|
| 626 |
** |
|---|
| 627 |
** Space to hold the [sqlite3_file] structure passed as the third |
|---|
| 628 |
** argument to xOpen is allocated by caller (the SQLite core). |
|---|
| 629 |
** szOsFile bytes are allocated for this object. The xOpen method |
|---|
| 630 |
** fills in the allocated space. |
|---|
| 631 |
** |
|---|
| 632 |
** The flags argument to xAccess() may be [SQLITE_ACCESS_EXISTS] |
|---|
| 633 |
** to test for the existance of a file, |
|---|
| 634 |
** or [SQLITE_ACCESS_READWRITE] to test to see |
|---|
| 635 |
** if a file is readable and writable, or [SQLITE_ACCESS_READ] |
|---|
| 636 |
** to test to see if a file is at least readable. The file can be a |
|---|
| 637 |
** directory. |
|---|
| 638 |
** |
|---|
| 639 |
** SQLite will always allocate at least mxPathname+1 byte for |
|---|
| 640 |
** the output buffers for xGetTempname and xFullPathname. The exact |
|---|
| 641 |
** size of the output buffer is also passed as a parameter to both |
|---|
| 642 |
** methods. If the output buffer is not large enough, SQLITE_CANTOPEN |
|---|
| 643 |
** should be returned. As this is handled as a fatal error by SQLite, |
|---|
| 644 |
** vfs implementations should endevour to prevent this by setting |
|---|
| 645 |
** mxPathname to a sufficiently large value. |
|---|
| 646 |
** |
|---|
| 647 |
** The xRandomness(), xSleep(), and xCurrentTime() interfaces |
|---|
| 648 |
** are not strictly a part of the filesystem, but they are |
|---|
| 649 |
** included in the VFS structure for completeness. |
|---|
| 650 |
** The xRandomness() function attempts to return nBytes bytes |
|---|
| 651 |
** of good-quality randomness into zOut. The return value is |
|---|
| 652 |
** the actual number of bytes of randomness obtained. The |
|---|
| 653 |
** xSleep() method cause the calling thread to sleep for at |
|---|
| 654 |
** least the number of microseconds given. The xCurrentTime() |
|---|
| 655 |
** method returns a Julian Day Number for the current date and |
|---|
| 656 |
** time. |
|---|
| 657 |
*/ |
|---|
| 658 |
struct sqlite3_vfs { |
|---|
| 659 |
int iVersion; /* Structure version number */ |
|---|
| 660 |
int szOsFile; /* Size of subclassed sqlite3_file */ |
|---|
| 661 |
int mxPathname; /* Maximum file pathname length */ |
|---|
| 662 |
sqlite3_vfs* pNext; /* Next registered VFS */ |
|---|
| 663 |
char* zName; /* Name of this virtual file system */ |
|---|
| 664 |
void* pAppData; /* Pointer to application-specific data */ |
|---|
| 665 |
int function(sqlite3_vfs*, char* zName, sqlite3_file*, int flags, int* pOutFlags) xOpen; |
|---|
| 666 |
int function(sqlite3_vfs*, char* zName, int syncDir) xDelete; |
|---|
| 667 |
int function(sqlite3_vfs*, char* zName, int flags) xAccess; |
|---|
| 668 |
int function(sqlite3_vfs*, int nOut, char* zOut) xGetTempName; |
|---|
| 669 |
int function(sqlite3_vfs*, char* zName, int nOut, char* zOut) xFullPathname; |
|---|
| 670 |
void* function(sqlite3_vfs*, char* zFileName) xDlOpen; |
|---|
| 671 |
void* function(sqlite3_vfs*, int nByte, char* zErrMsg) xDlError; |
|---|
| 672 |
void* function(sqlite3_vfs*, void*, char* zSymbol) xDlSym; |
|---|
| 673 |
void function(sqlite3_vfs*, void*) xDlClose; |
|---|
| 674 |
int function(sqlite3_vfs*, int nByte, char* zOut) xRandomness; |
|---|
| 675 |
int function(sqlite3_vfs*, int microseconds) xSleep; |
|---|
| 676 |
int function(sqlite3_vfs, double*) xCurrentTime; |
|---|
| 677 |
/* New fields may be appended in figure versions. The iVersion |
|---|
| 678 |
** value will increment whenever this happens. */ |
|---|
| 679 |
} |
|---|
| 680 |
|
|---|
| 681 |
/* |
|---|
| 682 |
** CAPI3REF: Flags for the xAccess VFS method |
|---|
| 683 |
** |
|---|
| 684 |
** These integer constants can be used as the third parameter to |
|---|
| 685 |
** the xAccess method of an [sqlite3_vfs] object. They determine |
|---|
| 686 |
** the kind of what kind of permissions the xAccess method is |
|---|
| 687 |
** looking for. With SQLITE_ACCESS_EXISTS, the xAccess method |
|---|
| 688 |
** simply checks to see if the file exists. With SQLITE_ACCESS_READWRITE, |
|---|
| 689 |
** the xAccess method checks to see if the file is both readable |
|---|
| 690 |
** and writable. With SQLITE_ACCESS_READ the xAccess method |
|---|
| 691 |
** checks to see if the file is readable. |
|---|
| 692 |
*/ |
|---|
| 693 |
const SQLITE_ACCESS_EXISTS = 0; |
|---|
| 694 |
const SQLITE_ACCESS_READWRITE = 1; |
|---|
| 695 |
const SQLITE_ACCESS_READ = 2; |
|---|
| 696 |
|
|---|
| 697 |
/* |
|---|
| 698 |
** CAPI3REF: Enable Or Disable Extended Result Codes |
|---|
| 699 |
** |
|---|
| 700 |
** This routine enables or disables the |
|---|
| 701 |
** [SQLITE_IOERR_READ | extended result codes] feature. |
|---|
| 702 |
** By default, SQLite API routines return one of only 26 integer |
|---|
| 703 |
** [SQLITE_OK | result codes]. When extended result codes |
|---|
| 704 |
** are enabled by this routine, the repetoire of result codes can be |
|---|
| 705 |
** much larger and can (hopefully) provide more detailed information |
|---|
| 706 |
** about the cause of an error. |
|---|
| 707 |
** |
|---|
| 708 |
** The second argument is a boolean value that turns extended result |
|---|
| 709 |
** codes on and off. Extended result codes are off by default for |
|---|
| 710 |
** backwards compatibility with older versions of SQLite. |
|---|
| 711 |
*/ |
|---|
| 712 |
int sqlite3_extended_result_codes(sqlite3*, int onoff); |
|---|
| 713 |
|
|---|
| 714 |
/* |
|---|
| 715 |
** CAPI3REF: Last Insert Rowid |
|---|
| 716 |
** |
|---|
| 717 |
** Each entry in an SQLite table has a unique 64-bit signed integer key |
|---|
| 718 |
** called the "rowid". The rowid is always available as an undeclared |
|---|
| 719 |
** column named ROWID, OID, or _ROWID_. If the table has a column of |
|---|
| 720 |
** type INTEGER PRIMARY KEY then that column is another an alias for the |
|---|
| 721 |
** rowid. |
|---|
| 722 |
** |
|---|
| 723 |
** This routine returns the rowid of the most recent INSERT into |
|---|
| 724 |
** the database from the database connection given in the first |
|---|
| 725 |
** argument. If no inserts have ever occurred on this database |
|---|
| 726 |
** connection, zero is returned. |
|---|
| 727 |
** |
|---|
| 728 |
** If an INSERT occurs within a trigger, then the rowid of the |
|---|
| 729 |
** inserted row is returned by this routine as long as the trigger |
|---|
| 730 |
** is running. But once the trigger terminates, the value returned |
|---|
| 731 |
** by this routine reverts to the last value inserted before the |
|---|
| 732 |
** trigger fired. |
|---|
| 733 |
** |
|---|
| 734 |
** If another thread does a new insert on the same database connection |
|---|
| 735 |
** while this routine is running and thus changes the last insert rowid, |
|---|
| 736 |
** then the return value of this routine is undefined. |
|---|
| 737 |
*/ |
|---|
| 738 |
sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*); |
|---|
| 739 |
|
|---|
| 740 |
/* |
|---|
| 741 |
** CAPI3REF: Count The Number Of Rows Modified |
|---|
| 742 |
** |
|---|
| 743 |
** This function returns the number of database rows that were changed |
|---|
| 744 |
** (or inserted or deleted) by the most recent SQL statement. Only |
|---|
| 745 |
** changes that are directly specified by the INSERT, UPDATE, or |
|---|
| 746 |
** DELETE statement are counted. Auxiliary changes caused by |
|---|
| 747 |
** triggers are not counted. Use the [sqlite3_total_changes()] function |
|---|
| 748 |
** to find the total number of changes including changes caused by triggers. |
|---|
| 749 |
** |
|---|
| 750 |
** Within the body of a trigger, the sqlite3_changes() interface can be |
|---|
| 751 |
** called to find the number of |
|---|
| 752 |
** changes in the most recently completed INSERT, UPDATE, or DELETE |
|---|
| 753 |
** statement within the body of the trigger. |
|---|
| 754 |
** |
|---|
| 755 |
** All changes are counted, even if they were later undone by a |
|---|
| 756 |
** ROLLBACK or ABORT. Except, changes associated with creating and |
|---|
| 757 |
** dropping tables are not counted. |
|---|
| 758 |
** |
|---|
| 759 |
** If a callback invokes [sqlite3_exec()] or [sqlite3_step()] recursively, |
|---|
| 760 |
** then the changes in the inner, recursive call are counted together |
|---|
| 761 |
** with the changes in the outer call. |
|---|
| 762 |
** |
|---|
| 763 |
** SQLite implements the command "DELETE FROM table" without a WHERE clause |
|---|
| 764 |
** by dropping and recreating the table. (This is much faster than going |
|---|
| 765 |
** through and deleting individual elements from the table.) Because of |
|---|
| 766 |
** this optimization, the change count for "DELETE FROM table" will be |
|---|
| 767 |
** zero regardless of the number of elements that were originally in the |
|---|
| 768 |
** table. To get an accurate count of the number of rows deleted, use |
|---|
| 769 |
** "DELETE FROM table WHERE 1" instead. |
|---|
| 770 |
** |
|---|
| 771 |
** If another thread makes changes on the same database connection |
|---|
| 772 |
** while this routine is running then the return value of this routine |
|---|
| 773 |
** is undefined. |
|---|
| 774 |
*/ |
|---|
| 775 |
int sqlite3_changes(sqlite3*); |
|---|
| 776 |
|
|---|
| 777 |
/* |
|---|
| 778 |
** CAPI3REF: Total Number Of Rows Modified |
|---|
| 779 |
*** |
|---|
| 780 |
** This function returns the number of database rows that have been |
|---|
| 781 |
** modified by INSERT, UPDATE or DELETE statements since the database handle |
|---|
| 782 |
** was opened. This includes UPDATE, INSERT and DELETE statements executed |
|---|
| 783 |
** as part of trigger programs. All changes are counted as soon as the |
|---|
| 784 |
** statement that makes them is completed (when the statement handle is |
|---|
| 785 |
** passed to [sqlite3_reset()] or [sqlite3_finalize()]). |
|---|
| 786 |
** |
|---|
| 787 |
** See also the [sqlite3_change()] interface. |
|---|
| 788 |
** |
|---|
| 789 |
** SQLite implements the command "DELETE FROM table" without a WHERE clause |
|---|
| 790 |
** by dropping and recreating the table. (This is much faster than going |
|---|
| 791 |
** through and deleting individual elements form the table.) Because of |
|---|
| 792 |
** this optimization, the change count for "DELETE FROM table" will be |
|---|
| 793 |
** zero regardless of the number of elements that were originally in the |
|---|
| 794 |
** table. To get an accurate count of the number of rows deleted, use |
|---|
| 795 |
** "DELETE FROM table WHERE 1" instead. |
|---|
| 796 |
** |
|---|
| 797 |
** If another thread makes changes on the same database connection |
|---|
| 798 |
** while this routine is running then the return value of this routine |
|---|
| 799 |
** is undefined. |
|---|
| 800 |
*/ |
|---|
| 801 |
int sqlite3_total_changes(sqlite3*); |
|---|
| 802 |
|
|---|
| 803 |
/* |
|---|
| 804 |
** CAPI3REF: Interrupt A Long-Running Query |
|---|
| 805 |
** |
|---|
| 806 |
** This function causes any pending database operation to abort and |
|---|
| 807 |
** return at its earliest opportunity. This routine is typically |
|---|
| 808 |
** called in response to a user action such as pressing "Cancel" |
|---|
| 809 |
** or Ctrl-C where the user wants a long query operation to halt |
|---|
| 810 |
** immediately. |
|---|