C/C++ Interface For SQLite Version 3
Note: Constants marked with "(exp)"are experimental and constants marked with"(obs)" are deprecated
SQLITE_ABORTSQLITE_ACCESS_EXISTSSQLITE_ACCESS_READSQLITE_ACCESS_READWRITESQLITE_ALTER_TABLESQLITE_ANALYZESQLITE_ANYSQLITE_ATTACHSQLITE_AUTHSQLITE_BLOBSQLITE_BUSYSQLITE_BUSY_RECOVERYSQLITE_CANTOPENSQLITE_CANTOPEN_NOTEMPDIRSQLITE_CHECKPOINT_FULLSQLITE_CHECKPOINT_PASSIVESQLITE_CHECKPOINT_RESTARTSQLITE_CONFIG_GETMALLOCSQLITE_CONFIG_GETMUTEXSQLITE_CONFIG_GETPCACHESQLITE_CONFIG_GETPCACHE2SQLITE_CONFIG_HEAPSQLITE_CONFIG_LOGSQLITE_CONFIG_LOOKASIDESQLITE_CONFIG_MALLOCSQLITE_CONFIG_MEMSTATUSSQLITE_CONFIG_MULTITHREADSQLITE_CONFIG_MUTEXSQLITE_CONFIG_PAGECACHESQLITE_CONFIG_PCACHESQLITE_CONFIG_PCACHE2SQLITE_CONFIG_SCRATCHSQLITE_CONFIG_SERIALIZEDSQLITE_CONFIG_SINGLETHREADSQLITE_CONFIG_URISQLITE_CONSTRAINTSQLITE_COPYSQLITE_CORRUPTSQLITE_CORRUPT_VTABSQLITE_CREATE_INDEXSQLITE_CREATE_TABLESQLITE_CREATE_TEMP_INDEXSQLITE_CREATE_TEMP_TABLESQLITE_CREATE_TEMP_TRIGGERSQLITE_CREATE_TEMP_VIEWSQLITE_CREATE_TRIGGERSQLITE_CREATE_VIEWSQLITE_CREATE_VTABLESQLITE_DBCONFIG_ENABLE_FKEYSQLITE_DBCONFIG_ENABLE_TRIGGERSQLITE_DBCONFIG_LOOKASIDESQLITE_DBSTATUS_CACHE_HITSQLITE_DBSTATUS_CACHE_MISSSQLITE_DBSTATUS_CACHE_USEDSQLITE_DBSTATUS_LOOKASIDE_HITSQLITE_DBSTATUS_LOOKASIDE_MISS_FULLSQLITE_DBSTATUS_LOOKASIDE_MISS_SIZESQLITE_DBSTATUS_LOOKASIDE_USEDSQLITE_DBSTATUS_MAXSQLITE_DBSTATUS_SCHEMA_USEDSQLITE_DBSTATUS_STMT_USEDSQLITE_DELETESQLITE_DENYSQLITE_DETACHSQLITE_DONESQLITE_DROP_INDEXSQLITE_DROP_TABLESQLITE_DROP_TEMP_INDEXSQLITE_DROP_TEMP_TABLESQLITE_DROP_TEMP_TRIGGERSQLITE_DROP_TEMP_VIEWSQLITE_DROP_TRIGGERSQLITE_DROP_VIEWSQLITE_DROP_VTABLESQLITE_EMPTYSQLITE_ERRORSQLITE_FAILSQLITE_FCNTL_CHUNK_SIZESQLITE_FCNTL_FILE_POINTERSQLITE_FCNTL_LOCKSTATESQLITE_FCNTL_OVERWRITESQLITE_FCNTL_PERSIST_WALSQLITE_FCNTL_POWERSAFE_OVERWRITESQLITE_FCNTL_SIZE_HINTSQLITE_FCNTL_SYNC_OMITTEDSQLITE_FCNTL_VFSNAMESQLITE_FCNTL_WIN32_AV_RETRYSQLITE_FLOATSQLITE_FORMATSQLITE_FULLSQLITE_FUNCTIONSQLITE_GET_LOCKPROXYFILESQLITE_IGNORESQLITE_INDEX_CONSTRAINT_EQSQLITE_INDEX_CONSTRAINT_GESQLITE_INDEX_CONSTRAINT_GTSQLITE_INDEX_CONSTRAINT_LESQLITE_INDEX_CONSTRAINT_LTSQLITE_INDEX_CONSTRAINT_MATCHSQLITE_INSERTSQLITE_INTEGERSQLITE_INTERNALSQLITE_INTERRUPTSQLITE_IOCAP_ATOMICSQLITE_IOCAP_ATOMIC16KSQLITE_IOCAP_ATOMIC1KSQLITE_IOCAP_ATOMIC2KSQLITE_IOCAP_ATOMIC32KSQLITE_IOCAP_ATOMIC4KSQLITE_IOCAP_ATOMIC512SQLITE_IOCAP_ATOMIC64KSQLITE_IOCAP_ATOMIC8KSQLITE_IOCAP_POWERSAFE_OVERWRITESQLITE_IOCAP_SAFE_APPENDSQLITE_IOCAP_SEQUENTIALSQLITE_IOCAP_UNDELETABLE_WHEN_OPENSQLITE_IOERRSQLITE_IOERR_ACCESSSQLITE_IOERR_BLOCKEDSQLITE_IOERR_CHECKRESERVEDLOCKSQLITE_IOERR_CLOSESQLITE_IOERR_DELETESQLITE_IOERR_DIR_CLOSESQLITE_IOERR_DIR_FSYNCSQLITE_IOERR_FSTATSQLITE_IOERR_FSYNCSQLITE_IOERR_LOCKSQLITE_IOERR_NOMEMSQLITE_IOERR_RDLOCKSQLITE_IOERR_READSQLITE_IOERR_SEEKSQLITE_IOERR_SHMLOCKSQLITE_IOERR_SHMMAPSQLITE_IOERR_SHMOPENSQLITE_IOERR_SHMSIZESQLITE_IOERR_SHORT_READSQLITE_IOERR_TRUNCATESQLITE_IOERR_UNLOCKSQLITE_IOERR_WRITESQLITE_LAST_ERRNOSQLITE_LIMIT_ATTACHEDSQLITE_LIMIT_COLUMNSQLITE_LIMIT_COMPOUND_SELECTSQLITE_LIMIT_EXPR_DEPTHSQLITE_LIMIT_FUNCTION_ARGSQLITE_LIMIT_LENGTHSQLITE_LIMIT_LIKE_PATTERN_LENGTHSQLITE_LIMIT_SQL_LENGTHSQLITE_LIMIT_TRIGGER_DEPTHSQLITE_LIMIT_VARIABLE_NUMBERSQLITE_LIMIT_VDBE_OPSQLITE_LOCKEDSQLITE_LOCKED_SHAREDCACHESQLITE_LOCK_EXCLUSIVESQLITE_LOCK_NONESQLITE_LOCK_PENDINGSQLITE_LOCK_RESERVEDSQLITE_LOCK_SHAREDSQLITE_MISMATCHSQLITE_MISUSESQLITE_MUTEX_FASTSQLITE_MUTEX_RECURSIVESQLITE_MUTEX_STATIC_LRUSQLITE_MUTEX_STATIC_LRU2SQLITE_MUTEX_STATIC_MASTERSQLITE_MUTEX_STATIC_MEMSQLITE_MUTEX_STATIC_MEM2SQLITE_MUTEX_STATIC_OPENSQLITE_MUTEX_STATIC_PMEMSQLITE_MUTEX_STATIC_PRNGSQLITE_NOLFSSQLITE_NOMEMSQLITE_NOTADBSQLITE_NOTFOUNDSQLITE_NULLSQLITE_OKSQLITE_OPEN_AUTOPROXYSQLITE_OPEN_CREATESQLITE_OPEN_DELETEONCLOSESQLITE_OPEN_EXCLUSIVESQLITE_OPEN_FULLMUTEXSQLITE_OPEN_MAIN_DBSQLITE_OPEN_MAIN_JOURNALSQLITE_OPEN_MASTER_JOURNALSQLITE_OPEN_NOMUTEXSQLITE_OPEN_PRIVATECACHESQLITE_OPEN_READONLYSQLITE_OPEN_READWRITESQLITE_OPEN_SHAREDCACHESQLITE_OPEN_SUBJOURNALSQLITE_OPEN_TEMP_DBSQLITE_OPEN_TEMP_JOURNALSQLITE_OPEN_TRANSIENT_DBSQLITE_OPEN_URISQLITE_OPEN_WALSQLITE_PERMSQLITE_PRAGMASQLITE_PROTOCOLSQLITE_RANGESQLITE_READSQLITE_READONLYSQLITE_READONLY_CANTLOCKSQLITE_READONLY_RECOVERYSQLITE_REINDEXSQLITE_REPLACESQLITE_ROLLBACKSQLITE_ROWSQLITE_SAVEPOINTSQLITE_SCHEMASQLITE_SELECTSQLITE_SET_LOCKPROXYFILESQLITE_SHM_EXCLUSIVESQLITE_SHM_LOCKSQLITE_SHM_NLOCKSQLITE_SHM_SHAREDSQLITE_SHM_UNLOCKSQLITE_SOURCE_IDSQLITE_STATICSQLITE_STATUS_MALLOC_COUNTSQLITE_STATUS_MALLOC_SIZESQLITE_STATUS_MEMORY_USEDSQLITE_STATUS_PAGECACHE_OVERFLOWSQLITE_STATUS_PAGECACHE_SIZESQLITE_STATUS_PAGECACHE_USEDSQLITE_STATUS_PARSER_STACKSQLITE_STATUS_SCRATCH_OVERFLOWSQLITE_STATUS_SCRATCH_SIZESQLITE_STATUS_SCRATCH_USEDSQLITE_STMTSTATUS_AUTOINDEXSQLITE_STMTSTATUS_FULLSCAN_STEPSQLITE_STMTSTATUS_SORTSQLITE_SYNC_DATAONLYSQLITE_SYNC_FULLSQLITE_SYNC_NORMALSQLITE_TESTCTRL_ALWAYSSQLITE_TESTCTRL_ASSERTSQLITE_TESTCTRL_BENIGN_MALLOC_HOOKSSQLITE_TESTCTRL_BITVEC_TESTSQLITE_TESTCTRL_EXPLAIN_STMTSQLITE_TESTCTRL_FAULT_INSTALLSQLITE_TESTCTRL_FIRSTSQLITE_TESTCTRL_ISKEYWORDSQLITE_TESTCTRL_LASTSQLITE_TESTCTRL_LOCALTIME_FAULTSQLITE_TESTCTRL_OPTIMIZATIONSSQLITE_TESTCTRL_PENDING_BYTESQLITE_TESTCTRL_PRNG_RESETSQLITE_TESTCTRL_PRNG_RESTORESQLITE_TESTCTRL_PRNG_SAVESQLITE_TESTCTRL_RESERVESQLITE_TESTCTRL_SCRATCHMALLOCSQLITE_TEXTSQLITE_TOOBIGSQLITE_TRANSACTIONSQLITE_TRANSIENTSQLITE_UPDATESQLITE_UTF16SQLITE_UTF16BESQLITE_UTF16LESQLITE_UTF16_ALIGNEDSQLITE_UTF8SQLITE_VERSIONSQLITE_VERSION_NUMBERSQLITE_VTAB_CONSTRAINT_SUPPORTFunctions:Note: Functions marked with "(exp)"are experimental and functions marked with(obs) are deprecated.
sqlite3_aggregate_contextsqlite3_aggregate_count??(obs)sqlite3_auto_extensionsqlite3_backup_finishsqlite3_backup_initsqlite3_backup_pagecountsqlite3_backup_remainingsqlite3_backup_stepsqlite3_bind_blobsqlite3_bind_doublesqlite3_bind_intsqlite3_bind_int64sqlite3_bind_nullsqlite3_bind_parameter_countsqlite3_bind_parameter_indexsqlite3_bind_parameter_namesqlite3_bind_textsqlite3_bind_text16sqlite3_bind_valuesqlite3_bind_zeroblobsqlite3_blob_bytessqlite3_blob_closesqlite3_blob_opensqlite3_blob_readsqlite3_blob_reopensqlite3_blob_writesqlite3_busy_handlersqlite3_busy_timeoutsqlite3_changessqlite3_clear_bindingssqlite3_closesqlite3_collation_neededsqlite3_collation_needed16sqlite3_column_blobsqlite3_column_bytessqlite3_column_bytes16sqlite3_column_countsqlite3_column_database_namesqlite3_column_database_name16sqlite3_column_decltypesqlite3_column_decltype16sqlite3_column_doublesqlite3_column_intsqlite3_column_int64sqlite3_column_namesqlite3_column_name16sqlite3_column_origin_namesqlite3_column_origin_name16sqlite3_column_table_namesqlite3_column_table_name16sqlite3_column_textsqlite3_column_text16sqlite3_column_typesqlite3_column_valuesqlite3_commit_hooksqlite3_compileoption_getsqlite3_compileoption_usedsqlite3_completesqlite3_complete16sqlite3_configsqlite3_context_db_handlesqlite3_create_collationsqlite3_create_collation16sqlite3_create_collation_v2sqlite3_create_functionsqlite3_create_function16sqlite3_create_function_v2sqlite3_create_modulesqlite3_create_module_v2sqlite3_data_countsqlite3_db_configsqlite3_db_filenamesqlite3_db_handlesqlite3_db_mutexsqlite3_db_release_memorysqlite3_db_statussqlite3_declare_vtabsqlite3_enable_load_extensionsqlite3_enable_shared_cachesqlite3_errcodesqlite3_errmsgsqlite3_errmsg16sqlite3_execsqlite3_expired??(obs)sqlite3_extended_errcodesqlite3_extended_result_codessqlite3_file_controlsqlite3_finalizesqlite3_freesqlite3_free_tablesqlite3_get_autocommitsqlite3_get_auxdatasqlite3_get_tablesqlite3_global_recover??(obs)sqlite3_initializesqlite3_interruptsqlite3_last_insert_rowidsqlite3_libversionsqlite3_libversion_numbersqlite3_limitsqlite3_load_extensionsqlite3_logsqlite3_mallocsqlite3_memory_alarm??(obs)sqlite3_memory_highwatersqlite3_memory_usedsqlite3_mprintfsqlite3_mutex_allocsqlite3_mutex_entersqlite3_mutex_freesqlite3_mutex_heldsqlite3_mutex_leavesqlite3_mutex_notheldsqlite3_mutex_trysqlite3_next_stmtsqlite3_opensqlite3_open16sqlite3_open_v2sqlite3_os_endsqlite3_os_initsqlite3_overload_functionsqlite3_preparesqlite3_prepare16sqlite3_prepare16_v2sqlite3_prepare_v2sqlite3_profilesqlite3_progress_handlersqlite3_randomnesssqlite3_reallocsqlite3_release_memorysqlite3_resetsqlite3_reset_auto_extensionsqlite3_result_blobsqlite3_result_doublesqlite3_result_errorsqlite3_result_error16sqlite3_result_error_codesqlite3_result_error_nomemsqlite3_result_error_toobigsqlite3_result_intsqlite3_result_int64sqlite3_result_nullsqlite3_result_textsqlite3_result_text16sqlite3_result_text16besqlite3_result_text16lesqlite3_result_valuesqlite3_result_zeroblobsqlite3_rollback_hooksqlite3_set_authorizersqlite3_set_auxdatasqlite3_shutdownsqlite3_sleepsqlite3_snprintfsqlite3_soft_heap_limit??(obs)sqlite3_soft_heap_limit64sqlite3_sourceidsqlite3_sqlsqlite3_statussqlite3_stepsqlite3_stmt_busysqlite3_stmt_readonlysqlite3_stmt_statussqlite3_strnicmpsqlite3_table_column_metadatasqlite3_test_controlsqlite3_thread_cleanup??(obs)sqlite3_threadsafesqlite3_total_changessqlite3_tracesqlite3_transfer_bindings??(obs)sqlite3_unlock_notifysqlite3_update_hooksqlite3_uri_booleansqlite3_uri_int64sqlite3_uri_parametersqlite3_user_datasqlite3_value_blobsqlite3_value_bytessqlite3_value_bytes16sqlite3_value_doublesqlite3_value_intsqlite3_value_int64sqlite3_value_numeric_typesqlite3_value_textsqlite3_value_text16sqlite3_value_text16besqlite3_value_text16lesqlite3_value_typesqlite3_version,sqlite3_vfs_findsqlite3_vfs_registersqlite3_vfs_unregistersqlite3_vmprintfsqlite3_vsnprintfsqlite3_vtab_configsqlite3_vtab_on_conflictsqlite3_wal_autocheckpointsqlite3_wal_checkpointsqlite3_wal_checkpoint_v2sqlite3_wal_hookMaximum xShmLock index#define SQLITE_SHM_NLOCK 8
The xShmLock method on sqlite3_io_methods may use valuesbetween 0 and this upper bound as its "offset" argument.The SQLite core will never attempt to acquire or release alock outside of this range
Virtual Table Configuration Options#define SQLITE_VTAB_CONSTRAINT_SUPPORT 1
These macros define the various options to thesqlite3_vtab_config() interface that virtual table implementationscan use to customize and optimize their behavior.
SQLITE_VTAB_CONSTRAINT_SUPPORTCalls of the formsqlite3_vtab_config(db,SQLITE_VTAB_CONSTRAINT_SUPPORT,X) are supported,where X is an integer. If X is zero, then the virtual table whosexCreate or xConnect method invoked sqlite3_vtab_config() does notsupport constraints. In this configuration (which is the default) ifa call to the xUpdate method returns SQLITE_CONSTRAINT, then the entirestatement is rolled back as if OR ABORT had beenspecified as part of the users SQL statement, regardless of the actualON CONFLICT mode specified.If X is non-zero, then the virtual table implementation guaranteesthat if xUpdate returns SQLITE_CONSTRAINT, it will do so beforeany modifications to internal or persistent data structures have been made.If the ON CONFLICT mode is ABORT, FAIL, IGNORE or ROLLBACK, SQLiteis able to roll back a statement or database transaction, and abandonor continue processing the current SQL statement as appropriate.If the ON CONFLICT mode is REPLACE and the xUpdate method returnsSQLITE_CONSTRAINT, SQLite handles this as if the ON CONFLICT modehad been ABORT.
Virtual table implementations that are required to handle OR REPLACEmust do so within the xUpdate method. If a call to thesqlite3_vtab_on_conflict() function indicates that the current ONCONFLICT policy is REPLACE, the virtual table implementation shouldsilently replace the appropriate rows within the xUpdate callback andreturn SQLITE_OK. Or, if this is not possible, it may returnSQLITE_CONSTRAINT, in which case SQLite falls back to OR ABORTconstraint handling.
Online Backup Objecttypedef struct sqlite3_backup sqlite3_backup;
The sqlite3_backup object records state information about an ongoingonline backup operation. The sqlite3_backup object is created bya call to sqlite3_backup_init() and is destroyed by a call tosqlite3_backup_finish().
See Also: Using the SQLite Online Backup API
SQL Function Context Objecttypedef struct sqlite3_context sqlite3_context;
The context in which an SQL function executes is stored in ansqlite3_context object. A pointer to an sqlite3_context objectis always first parameter to application-defined SQL functions.The application-defined SQL function implementation will pass thispointer through into calls to sqlite3_result(),sqlite3_aggregate_context(), sqlite3_user_data(),sqlite3_context_db_handle(), sqlite3_get_auxdata(),and/or sqlite3_set_auxdata().
OS Interface Open File Handle
typedef struct sqlite3_file sqlite3_file;struct sqlite3_file { const struct sqlite3_io_methods *pMethods; /* Methods for an open file */};An sqlite3_file object represents an open file in theOS interface layer. Individual OS interfaceimplementations willwant to subclass this object by appending additional fieldsfor their own use. The pMethods entry is a pointer to ansqlite3_io_methods object that defines methods for performingI/O operations on the open file.
Virtual Table Indexing Informationstruct sqlite3_index_info { /* Inputs */ int nConstraint; /* Number of entries in aConstraint */ struct sqlite3_index_constraint { int iColumn; /* Column on left-hand side of constraint */ unsigned char op; /* Constraint operator */ unsigned char usable; /* True if this constraint is usable */ int iTermOffset; /* Used internally - xBestIndex should ignore */ } *aConstraint; /* Table of WHERE clause constraints */ int nOrderBy; /* Number of terms in the ORDER BY clause */ struct sqlite3_index_orderby { int iColumn; /* Column number */ unsigned char desc; /* True for DESC. False for ASC. */ } *aOrderBy; /* The ORDER BY clause */ /* Outputs */ struct sqlite3_index_constraint_usage { int argvIndex; /* if >0, constraint is part of argv to xFilter */ unsigned char omit; /* Do not code a test for this constraint */ } *aConstraintUsage; int idxNum; /* Number used to identify the index */ char *idxStr; /* String, possibly obtained from sqlite3_malloc */ int needToFreeIdxStr; /* Free idxStr using sqlite3_free() if true */ int orderByConsumed; /* True if output is already ordered */ double estimatedCost; /* Estimated cost of using this index */};The sqlite3_index_info structure and its substructures is used as partof the virtual table interface topass information into and receive the reply from the xBestIndexmethod of a virtual table module. The fields under **Inputs** are theinputs to xBestIndex and are read-only. xBestIndex inserts itsresults into the **Outputs** fields.
The aConstraint[] array records WHERE clause constraints of the form:
column OP expr
where OP is =, <, <=, >, or >=. The particular operator isstored in aConstraint[].op using one of theSQLITE_INDEX_CONSTRAINT_ values.The index of the column is stored inaConstraint[].iColumn. aConstraint[].usable is TRUE if theexpr on the right-hand side can be evaluated (and thus the constraintis usable) and false if it cannot.
The optimizer automatically inverts terms of the form "expr OP column"and makes other simplifications to the WHERE clause in an attempt toget as many WHERE clause terms into the form shown above as possible.The aConstraint[] array only reports WHERE clause terms that arerelevant to the particular virtual table being queried.
Information about the ORDER BY clause is stored in aOrderBy[].Each term of aOrderBy records a column of the ORDER BY clause.
The xBestIndex method must fill aConstraintUsage[] with informationabout what parameters to pass to xFilter. If argvIndex>0 thenthe right-hand side of the corresponding aConstraint[] is evaluatedand becomes the argvIndex-th entry in argv. If aConstraintUsage[].omitis true, then the constraint is assumed to be fully handled by thevirtual table and is not checked again by SQLite.
The idxNum and idxPtr values are recorded and passed into thexFilter method.sqlite3_free() is used to free idxPtr if and only ifneedToFreeIdxPtr is true.
The orderByConsumed means that output from xFilter/xNext will occur inthe correct order to satisfy the ORDER BY clause so that no separatesorting step is required.
The estimatedCost value is an estimate of the cost of doing theparticular lookup. A full scan of a table with N entries should havea cost of N. A binary search of a table of N entries should have acost of approximately log(N).
OS Interface File Virtual Methods Objecttypedef struct sqlite3_io_methods sqlite3_io_methods;struct sqlite3_io_methods { int iVersion; int (*xClose)(sqlite3_file*); int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst); int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite3_int64 iOfst); int (*xTruncate)(sqlite3_file*, sqlite3_int64 size); int (*xSync)(sqlite3_file*, int flags); int (*xFileSize)(sqlite3_file*, sqlite3_int64 *pSize); int (*xLock)(sqlite3_file*, int); int (*xUnlock)(sqlite3_file*, int); int (*xCheckReservedLock)(sqlite3_file*, int *pResOut); int (*xFileControl)(sqlite3_file*, int op, void *pArg); int (*xSectorSize)(sqlite3_file*); int (*xDeviceCharacteristics)(sqlite3_file*); /* Methods above are valid for version 1 */ int (*xShmMap)(sqlite3_file*, int iPg, int pgsz, int, void volatile**); int (*xShmLock)(sqlite3_file*, int offset, int n, int flags); void (*xShmBarrier)(sqlite3_file*); int (*xShmUnmap)(sqlite3_file*, int deleteFlag); /* Methods above are valid for version 2 */ /* Additional methods may be added in future releases */};Every file opened by the sqlite3_vfs.xOpen method populates ansqlite3_file object (or, more commonly, a subclass of thesqlite3_file object) with a pointer to an instance of this object.This object defines the methods used to perform various operationsagainst the open file represented by the sqlite3_file object.
If the sqlite3_vfs.xOpen method sets the sqlite3_file.pMethods elementto a non-NULL pointer, then the sqlite3_io_methods.xClose methodmay be invoked even if the sqlite3_vfs.xOpen reported that it failed. Theonly way to prevent a call to xClose following a failed sqlite3_vfs.xOpenis for the sqlite3_vfs.xOpen to set the sqlite3_file.pMethods elementto NULL.
The flags argument to xSync may be one of SQLITE_SYNC_NORMAL orSQLITE_SYNC_FULL. The first choice is the normal fsync().The second choice is a Mac OS X style fullsync. The SQLITE_SYNC_DATAONLYflag may be ORed in to indicate that only the data of the fileand not its inode needs to be synced.
The integer values to xLock() and xUnlock() are one of
SQLITE_LOCK_NONE, SQLITE_LOCK_SHARED, SQLITE_LOCK_RESERVED, SQLITE_LOCK_PENDING, or SQLITE_LOCK_EXCLUSIVE.xLock() increases the lock. xUnlock() decreases the lock.The xCheckReservedLock() method checks whether any database connection,either in this process or in some other process, is holding a RESERVED,PENDING, or EXCLUSIVE lock on the file. It returns trueif such a lock exists and false otherwise.
The xFileControl() method is a generic interface that allows customVFS implementations to directly control an open file using thesqlite3_file_control() interface. The second "op" argument is aninteger opcode. The third argument is a generic pointer intended topoint to a structure that may contain arguments or space in which towrite return values. Potential uses for xFileControl() might befunctions to enable blocking locks with timeouts, to change thelocking strategy (for example to use dot-file locks), to inquireabout the status of a lock, or to break stale locks. The SQLitecore reserves all opcodes less than 100 for its own use.A list of opcodes less than 100 is available.Applications that define a custom xFileControl method should use opcodesgreater than 100 to avoid conflicts. VFS implementations shouldreturn SQLITE_NOTFOUND for file control opcodes that they do notrecognize.
The xSectorSize() method returns the sector size of thedevice that underlies the file. The sector size is theminimum write that can be performed without disturbingother bytes in the file. The xDeviceCharacteristics()method returns a bit vector describing behaviors of theunderlying device:
SQLITE_IOCAP_ATOMIC SQLITE_IOCAP_ATOMIC512 SQLITE_IOCAP_ATOMIC1K SQLITE_IOCAP_ATOMIC2K SQLITE_IOCAP_ATOMIC4K SQLITE_IOCAP_ATOMIC8K SQLITE_IOCAP_ATOMIC16K SQLITE_IOCAP_ATOMIC32K SQLITE_IOCAP_ATOMIC64K SQLITE_IOCAP_SAFE_APPEND SQLITE_IOCAP_SEQUENTIALThe SQLITE_IOCAP_ATOMIC property means that all writes ofany size are atomic. The SQLITE_IOCAP_ATOMICnnn valuesmean that writes of blocks that are nnn bytes in size andare aligned to an address which is an integer multiple ofnnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value meansthat when data is appended to a file, the data is appendedfirst then the size of the file is extended, never the otherway around. The SQLITE_IOCAP_SEQUENTIAL property means thatinformation is written to disk in the same order as callsto xWrite().
If xRead() returns SQLITE_IOERR_SHORT_READ it must also fillin the unread portions of the buffer with zeros. A VFS thatfails to zero-fill short reads might seem to work. However,failure to zero-fill short reads will eventually lead todatabase corruption.
Memory Allocation Routinestypedef struct sqlite3_mem_methods sqlite3_mem_methods;struct sqlite3_mem_methods { void *(*xMalloc)(int); /* Memory allocation function */ void (*xFree)(void*); /* Free a prior allocation */ void *(*xRealloc)(void*,int); /* Resize an allocation */ int (*xSize)(void*); /* Return the size of an allocation */ int (*xRoundup)(int); /* Round up request size to allocation size */ int (*xInit)(void*); /* Initialize the memory allocator */ void (*xShutdown)(void*); /* Deinitialize the memory allocator */ void *pAppData; /* Argument to xInit() and xShutdown() */};An instance of this object defines the interface between SQLiteand low-level memory allocation routines.
This object is used in only one place in the SQLite interface.A pointer to an instance of this object is the argument tosqlite3_config() when the configuration option isSQLITE_CONFIG_MALLOC or SQLITE_CONFIG_GETMALLOC.By creating an instance of this objectand passing it to sqlite3_config(SQLITE_CONFIG_MALLOC)during configuration, an application can specify an alternativememory allocation subsystem for SQLite to use for all of itsdynamic memory needs.
Note that SQLite comes with several built-in memory allocatorsthat are perfectly adequate for the overwhelming majority of applicationsand that this object is only useful to a tiny minority of applicationswith specialized memory allocation requirements. This object isalso used during testing of SQLite in order to specify an alternativememory allocator that simulates memory out-of-memory conditions inorder to verify that SQLite recovers gracefully from suchconditions.
The xMalloc, xRealloc, and xFree methods must work like themalloc(), realloc() and free() functions from the standard C library.SQLite guarantees that the second argument toxRealloc is always a value returned by a prior call to xRoundup.
xSize should return the allocated size of a memory allocationpreviously obtained from xMalloc or xRealloc. The allocated sizeis always at least as big as the requested size but may be larger.
The xRoundup method returns what would be the allocated size ofa memory allocation given a particular requested size. Most memoryallocators round up memory allocations at least to the next multipleof 8. Some allocators round up to a larger multiple or to a power of 2.Every memory allocation request coming in through sqlite3_malloc()or sqlite3_realloc() first calls xRoundup. If xRoundup returns 0,that causes the corresponding memory allocation to fail.
The xInit method initializes the memory allocator. (For example,it might allocate any require mutexes or initialize internal datastructures. The xShutdown method is invoked (indirectly) bysqlite3_shutdown() and should deallocate any resources acquiredby xInit. The pAppData pointer is used as the only parameter toxInit and xShutdown.
SQLite holds the SQLITE_MUTEX_STATIC_MASTER mutex when it invokesthe xInit method, so the xInit method need not be threadsafe. ThexShutdown method is only called from sqlite3_shutdown() so it doesnot need to be threadsafe either. For all other methods, SQLiteholds the SQLITE_MUTEX_STATIC_MEM mutex as long as theSQLITE_CONFIG_MEMSTATUS configuration option is turned on (whichit is by default) and so the methods are automatically serialized.However, if SQLITE_CONFIG_MEMSTATUS is disabled, then the othermethods must be threadsafe or else make their own arrangements forserialization.
SQLite will never invoke xInit() more than once without an interveningcall to xShutdown().
Mutex Handletypedef struct sqlite3_mutex sqlite3_mutex;
The mutex module within SQLite defines sqlite3_mutex to be anabstract type for a mutex object. The SQLite core never looksat the internal representation of an sqlite3_mutex. It onlydeals with pointers to the sqlite3_mutex object.
Mutexes are created using sqlite3_mutex_alloc().
Mutex Methods Objecttypedef struct sqlite3_mutex_methods sqlite3_mutex_methods;struct sqlite3_mutex_methods { int (*xMutexInit)(void); int (*xMutexEnd)(void); sqlite3_mutex *(*xMutexAlloc)(int); void (*xMutexFree)(sqlite3_mutex *); void (*xMutexEnter)(sqlite3_mutex *); int (*xMutexTry)(sqlite3_mutex *); void (*xMutexLeave)(sqlite3_mutex *); int (*xMutexHeld)(sqlite3_mutex *); int (*xMutexNotheld)(sqlite3_mutex *);};An instance of this structure defines the low-level routinesused to allocate and use mutexes.
Usually, the default mutex implementations provided by SQLite aresufficient, however the user has the option of substituting a customimplementation for specialized deployments or systems for which SQLitedoes not provide a suitable implementation. In this case, the usercreates and populates an instance of this structure to passto sqlite3_config() along with the SQLITE_CONFIG_MUTEX option.Additionally, an instance of this structure can be used as anoutput variable when querying the system for the current muteximplementation, using the SQLITE_CONFIG_GETMUTEX option.
The xMutexInit method defined by this structure is invoked aspart of system initialization by the sqlite3_initialize() function.The xMutexInit routine is called by SQLite exactly once for eacheffective call to sqlite3_initialize().
The xMutexEnd method defined by this structure is invoked aspart of system shutdown by the sqlite3_shutdown() function. Theimplementation of this method is expected to release all outstandingresources obtained by the mutex methods implementation, especiallythose obtained by the xMutexInit method. The xMutexEnd()interface is invoked exactly once for each call to sqlite3_shutdown().
The remaining seven methods defined by this structure (xMutexAlloc,xMutexFree, xMutexEnter, xMutexTry, xMutexLeave, xMutexHeld andxMutexNotheld) implement the following interfaces (respectively):
sqlite3_mutex_alloc() sqlite3_mutex_free() sqlite3_mutex_enter() sqlite3_mutex_try() sqlite3_mutex_leave() sqlite3_mutex_held() sqlite3_mutex_notheld()The only difference is that the public sqlite3_XXX functions enumeratedabove silently ignore any invocations that pass a NULL pointer insteadof a valid mutex handle. The implementations of the methods definedby this structure are not required to handle this case, the resultsof passing a NULL pointer instead of a valid mutex handle are undefined(i.e. it is acceptable to provide an implementation that segfaults ifit is passed a NULL pointer).
The xMutexInit() method must be threadsafe. It must be harmless toinvoke xMutexInit() multiple times within the same process and withoutintervening calls to xMutexEnd(). Second and subsequent calls toxMutexInit() must be no-ops.
xMutexInit() must not use SQLite memory allocation (sqlite3_malloc()and its associates). Similarly, xMutexAlloc() must not use SQLite memoryallocation for a static mutex. However xMutexAlloc() may use SQLitememory allocation for a fast or recursive mutex.
SQLite will invoke the xMutexEnd() method when sqlite3_shutdown() iscalled, but only if the prior call to xMutexInit returned SQLITE_OK.If xMutexInit fails in any way, it is expected to clean up after itselfprior to returning.
Custom Page Cache Objecttypedef struct sqlite3_pcache sqlite3_pcache;
The sqlite3_pcache type is opaque. It is implemented bythe pluggable module. The SQLite core has no knowledge ofits size or internal structure and never deals with thesqlite3_pcache object except by holding and passing pointersto the object.
See sqlite3_pcache_methods2 for additional information.
Custom Page Cache Objecttypedef struct sqlite3_pcache_page sqlite3_pcache_page;struct sqlite3_pcache_page { void *pBuf; /* The content of the page */ void *pExtra; /* Extra information associated with the page */};The sqlite3_pcache_page object represents a single page in thepage cache. The page cache will allocate instances of thisobject. Various methods of the page cache use pointers to instancesof this object as parameters or as their return value.
See sqlite3_pcache_methods2 for additional information.
Name Of The Folder Holding Temporary FilesSQLITE_EXTERN char *sqlite3_temp_directory;
If this global variable is made to point to a string which isthe name of a folder (a.k.a. directory), then all temporary filescreated by SQLite when using a built-in VFSwill be placed in that directory. If this variableis a NULL pointer, then SQLite performs a search for an appropriatetemporary file directory.
It is not safe to read or modify this variable in more than onethread at a time. It is not safe to read or modify this variableif a database connection is being used at the same time in a separatethread.It is intended that this variable be set onceas part of process initialization and before any SQLite interfaceroutines have been called and that this variable remain unchangedthereafter.
The temp_store_directory pragma may modify this variable and causeit to point to memory obtained from sqlite3_malloc. Furthermore,the temp_store_directory pragma always assumes that any stringthat this variable points to is held in memory obtained fromsqlite3_malloc and the pragma may attempt to free that memoryusing sqlite3_free.Hence, if this variable is modified directly, either it should bemade NULL or made to point to memory obtained from sqlite3_mallocor else the use of the temp_store_directory pragma should be avoided.
OS Interface Objecttypedef struct sqlite3_vfs sqlite3_vfs;typedef void (*sqlite3_syscall_ptr)(void);struct sqlite3_vfs { int iVersion; /* Structure version number (currently 3) */ int szOsFile; /* Size of subclassed sqlite3_file */ int mxPathname; /* Maximum file pathname length */ sqlite3_vfs *pNext; /* Next registered VFS */ const char *zName; /* Name of this virtual file system */ void *pAppData; /* Pointer to application-specific data */ int (*xOpen)(sqlite3_vfs*, const char *zName, sqlite3_file*, int flags, int *pOutFlags); int (*xDelete)(sqlite3_vfs*, const char *zName, int syncDir); int (*xAccess)(sqlite3_vfs*, const char *zName, int flags, int *pResOut); int (*xFullPathname)(sqlite3_vfs*, const char *zName, int nOut, char *zOut); void *(*xDlOpen)(sqlite3_vfs*, const char *zFilename); void (*xDlError)(sqlite3_vfs*, int nByte, char *zErrMsg); void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void); void (*xDlClose)(sqlite3_vfs*, void*); int (*xRandomness)(sqlite3_vfs*, int nByte, char *zOut); int (*xSleep)(sqlite3_vfs*, int microseconds); int (*xCurrentTime)(sqlite3_vfs*, double*); int (*xGetLastError)(sqlite3_vfs*, int, char *); /* ** The methods above are in version 1 of the sqlite_vfs object ** definition. Those that follow are added in version 2 or later */ int (*xCurrentTimeInt64)(sqlite3_vfs*, sqlite3_int64*); /* ** The methods above are in versions 1 and 2 of the sqlite_vfs object. ** Those below are for version 3 and greater. */ int (*xSetSystemCall)(sqlite3_vfs*, const char *zName, sqlite3_syscall_ptr); sqlite3_syscall_ptr (*xGetSystemCall)(sqlite3_vfs*, const char *zName); const char *(*xNextSystemCall)(sqlite3_vfs*, const char *zName); /* ** The methods above are in versions 1 through 3 of the sqlite_vfs object. ** New fields may be appended in figure versions. The iVersion ** value will increment whenever this happens. */};An instance of the sqlite3_vfs object defines the interface betweenthe SQLite core and the underlying operating system. The "vfs"in the name of the object stands for "virtual file system". Seethe VFS documentation for further information.
The value of the iVersion field is initially 1 but may be larger infuture versions of SQLite. Additional fields may be appended to thisobject when the iVersion value is increased. Note that the structureof the sqlite3_vfs object changes in the transaction betweenSQLite version 3.5.9 and 3.6.0 and yet the iVersion field was notmodified.
The szOsFile field is the size of the subclassed sqlite3_filestructure used by this VFS. mxPathname is the maximum length ofa pathname in this VFS.
Registered sqlite3_vfs objects are kept on a linked list formed bythe pNext pointer. The sqlite3_vfs_register()and sqlite3_vfs_unregister() interfaces manage this listin a thread-safe way. The sqlite3_vfs_find() interfacesearches the list. Neither the application code nor the VFSimplementation should use the pNext pointer.
The pNext field is the only field in the sqlite3_vfsstructure that SQLite will ever modify. SQLite will only accessor modify this field while holding a particular static mutex.The application should never modify anything within the sqlite3_vfsobject once the object has been registered.
The zName field holds the name of the VFS module. The name mustbe unique across all VFS modules.
SQLite guarantees that the zFilename parameter to xOpenis either a NULL pointer or string obtainedfrom xFullPathname() with an optional suffix added.If a suffix is added to the zFilename parameter, it willconsist of a single "-" character followed by no more than11 alphanumeric and/or "-" characters.SQLite further guarantees thatthe string will be valid and unchanged until xClose() iscalled. Because of the previous sentence,the sqlite3_file can safely store a pointer to thefilename if it needs to remember the filename for some reason.If the zFilename parameter to xOpen is a NULL pointer then xOpenmust invent its own temporary name for the file. Whenever thexFilename parameter is NULL it will also be the case that theflags parameter will include SQLITE_OPEN_DELETEONCLOSE.
The flags argument to xOpen() includes all bits set inthe flags argument to sqlite3_open_v2(). Or if sqlite3_open()or sqlite3_open16() is used, then flags includes at leastSQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE.If xOpen() opens a file read-only then it sets *pOutFlags toinclude SQLITE_OPEN_READONLY. Other bits in *pOutFlags may be set.
SQLite will also add one of the following flags to the xOpen()call, depending on the object being opened:
SQLITE_OPEN_MAIN_DB SQLITE_OPEN_MAIN_JOURNAL SQLITE_OPEN_TEMP_DB SQLITE_OPEN_TEMP_JOURNAL SQLITE_OPEN_TRANSIENT_DB SQLITE_OPEN_SUBJOURNAL SQLITE_OPEN_MASTER_JOURNAL SQLITE_OPEN_WALThe file I/O implementation can use the object type flags tochange the way it deals with files. For example, an applicationthat does not care about crash recovery or rollback might makethe open of a journal file a no-op. Writes to this journal wouldalso be no-ops, and any attempt to read the journal would returnSQLITE_IOERR. Or the implementation might recognize that a databasefile will be doing page-aligned sector reads and writes in a randomorder and set up its I/O subsystem accordingly.
SQLite might also add one of the following flags to the xOpen method:
SQLITE_OPEN_DELETEONCLOSE SQLITE_OPEN_EXCLUSIVEThe SQLITE_OPEN_DELETEONCLOSE flag means the file should bedeleted when it is closed. The SQLITE_OPEN_DELETEONCLOSEwill be set for TEMP databases and their journals, transientdatabases, and subjournals.
The SQLITE_OPEN_EXCLUSIVE flag is always used in conjunctionwith the SQLITE_OPEN_CREATE flag, which are both directlyanalogous to the O_EXCL and O_CREAT flags of the POSIX open()API. The SQLITE_OPEN_EXCLUSIVE flag, when paired with theSQLITE_OPEN_CREATE, is used to indicate that file should alwaysbe created, and that it is an error if it already exists.It is not used to indicate the file should be openedfor exclusive access.
At least szOsFile bytes of memory are allocated by SQLiteto hold the sqlite3_file structure passed as the thirdargument to xOpen. The xOpen method does not have toallocate the structure; it should just fill it in. Note thatthe xOpen method must set the sqlite3_file.pMethods to eithera valid sqlite3_io_methods object or to NULL. xOpen must dothis even if the open fails. SQLite expects that the sqlite3_file.pMethodselement will be valid after xOpen returns regardless of the successor failure of the xOpen call.
The flags argument to xAccess() may be SQLITE_ACCESS_EXISTSto test for the existence of a file, or SQLITE_ACCESS_READWRITE totest whether a file is readable and writable, or SQLITE_ACCESS_READto test whether a file is at least readable. The file can be adirectory.
SQLite will always allocate at least mxPathname+1 bytes for theoutput buffer xFullPathname. The exact size of the output bufferis also passed as a parameter to both methods. If the output bufferis not large enough, SQLITE_CANTOPEN should be returned. Since this ishandled as a fatal error by SQLite, vfs implementations should endeavorto prevent this by setting mxPathname to a sufficiently large value.
The xRandomness(), xSleep(), xCurrentTime(), and xCurrentTimeInt64()interfaces are not strictly a part of the filesystem, but they areincluded in the VFS structure for completeness.The xRandomness() function attempts to return nBytes bytesof good-quality randomness into zOut. The return value isthe actual number of bytes of randomness obtained.The xSleep() method causes the calling thread to sleep for atleast the number of microseconds given. The xCurrentTime()method returns a Julian Day Number for the current date and time asa floating point value.The xCurrentTimeInt64() method returns, as an integer, the JulianDay Number multiplied by 86400000 (the number of milliseconds ina 24-hour day).SQLite will use the xCurrentTimeInt64() method to get the currentdate and time if that method is available (if iVersion is 2 orgreater and the function pointer is not NULL) and will fall backto xCurrentTime() if xCurrentTimeInt64() is unavailable.
The xSetSystemCall(), xGetSystemCall(), and xNestSystemCall() interfacesare not used by the SQLite core. These optional interfaces are providedby some VFSes to facilitate testing of the VFS code. By overridingsystem calls with functions under its control, a test program cansimulate faults and error conditions that would otherwise be difficultor impossible to induce. The set of system calls that can be overriddenvaries from one VFS to another, and from one version of the same VFS to thenext. Applications that use these interfaces must be prepared for anyor all of these interfaces to be NULL or for their behavior to changefrom one release to the next. Applications must not attempt to accessany of these methods if the iVersion of the VFS is less than 3.
Virtual Table Instance Objectstruct sqlite3_vtab { const sqlite3_module *pModule; /* The module for this virtual table */ int nRef; /* NO LONGER USED */ char *zErrMsg; /* Error message from sqlite3_mprintf() */ /* Virtual table implementations will typically add additional fields */};Every virtual table module implementation uses a subclassof this object to describe a particular instanceof the virtual table. Each subclass willbe tailored to the specific needs of the module implementation.The purpose of this superclass is to define certain fields that arecommon to all module implementations.
Virtual tables methods can set an error message by assigning astring obtained from sqlite3_mprintf() to zErrMsg. The method shouldtake care that any prior string is freed by a call to sqlite3_free()prior to assigning a new string to zErrMsg. After the error messageis delivered up to the client application, the string will be automaticallyfreed by sqlite3_free() and the zErrMsg field will be zeroed.
Obtain Aggregate Function Contextvoid *sqlite3_aggregate_context(sqlite3_context*, int nBytes);
Implementations of aggregate SQL functions use thisroutine to allocate memory for storing their state.
The first time the sqlite3_aggregate_context(C,N) routine is calledfor a particular aggregate function, SQLiteallocates N of memory, zeroes out that memory, and returns a pointerto the new memory. On second and subsequent calls tosqlite3_aggregate_context() for the same aggregate function instance,the same buffer is returned. Sqlite3_aggregate_context() is normallycalled once for each invocation of the xStep callback and then onelast time when the xFinal callback is invoked. When no rows matchan aggregate query, the xStep() callback of the aggregate functionimplementation is never called and xFinal() is called exactly once.In those cases, sqlite3_aggregate_context() might be called for thefirst time from within xFinal().
The sqlite3_aggregate_context(C,N) routine returns a NULL pointer if N isless than or equal to zero or if a memory allocate error occurs.
The amount of space allocated by sqlite3_aggregate_context(C,N) isdetermined by the N parameter on first successful call. Changing thevalue of N in subsequent call to sqlite3_aggregate_context() withinthe same aggregate function instance will not resize the memoryallocation.
SQLite automatically frees the memory allocated bysqlite3_aggregate_context() when the aggregate query concludes.
The first parameter must be a copy of theSQL function context that is the first parameterto the xStep or xFinal callback routine that implements the aggregatefunction.
This routine must be called from the same thread in whichthe aggregate SQL function is running.
Automatically Load Statically Linked Extensionsint sqlite3_auto_extension(void (*xEntryPoint)(void));
This interface causes the xEntryPoint() function to be invoked foreach new database connection that is created. The idea here is thatxEntryPoint() is the entry point for a statically linked SQLite extensionthat is to be automatically loaded into all new database connections.
Even though the function prototype shows that xEntryPoint() takesno arguments and returns void, SQLite invokes xEntryPoint() with threearguments and expects and integer result as if the signature of theentry point where as follows:
? int xEntryPoint(? sqlite3 *db,? const char **pzErrMsg,? const struct sqlite3_api_routines *pThunk? );
If the xEntryPoint routine encounters an error, it should make *pzErrMsgpoint to an appropriate error message (obtained from sqlite3_mprintf())and return an appropriate error code. SQLite ensures that *pzErrMsgis NULL before calling the xEntryPoint(). SQLite will invokesqlite3_free() on *pzErrMsg after xEntryPoint() returns. If anyxEntryPoint() returns an error, the sqlite3_open(), sqlite3_open16(),or sqlite3_open_v2() call that provoked the xEntryPoint() will fail.
Calling sqlite3_auto_extension(X) with an entry point X that is alreadyon the list of automatic extensions is a harmless no-op. No entry pointwill be called more than once for each database connection that is opened.
See also: sqlite3_reset_auto_extension().
Number Of SQL Parametersint sqlite3_bind_parameter_count(sqlite3_stmt*);
This routine can be used to find the number of SQL parametersin a prepared statement. SQL parameters are tokens of theform "?", "?NNN", ":AAA", "$AAA", or "@AAA" that serve asplaceholders for values that are boundto the parameters at a later time.
This routine actually returns the index of the largest (rightmost)parameter. For all forms except ?NNN, this will correspond to thenumber of unique parameters. If parameters of the ?NNN form are used,there may be gaps in the list.
See also: sqlite3_bind(),sqlite3_bind_parameter_name(), andsqlite3_bind_parameter_index().
Index Of A Parameter With A Given Nameint sqlite3_bind_parameter_index(sqlite3_stmt*, const char *zName);
Return the index of an SQL parameter given its name. Theindex value returned is suitable for use as the secondparameter to sqlite3_bind(). A zerois returned if no matching parameter is found. The parametername must be given in UTF-8 even if the original statementwas prepared from UTF-16 text using sqlite3_prepare16_v2().
See also: sqlite3_bind(),sqlite3_bind_parameter_count(), andsqlite3_bind_parameter_index().
Name Of A Host Parameterconst char *sqlite3_bind_parameter_name(sqlite3_stmt*, int);
The sqlite3_bind_parameter_name(P,N) interface returnsthe name of the N-th SQL parameter in the prepared statement P.SQL parameters of the form "?NNN" or ":AAA" or "@AAA" or "$AAA"have a name which is the string "?NNN" or ":AAA" or "@AAA" or "$AAA"respectively.In other words, the initial ":" or "$" or "@" or "?"is included as part of the name.Parameters of the form "?" without a following integer have no nameand are referred to as "nameless" or "anonymous parameters".
The first host parameter has an index of 1, not 0.
If the value N is out of range or if the N-th parameter isnameless, then NULL is returned. The returned string isalways in UTF-8 encoding even if the named parameter wasoriginally specified as UTF-16 in sqlite3_prepare16() orsqlite3_prepare16_v2().
See also: sqlite3_bind(),sqlite3_bind_parameter_count(), andsqlite3_bind_parameter_index().
Return The Size Of An Open BLOBint sqlite3_blob_bytes(sqlite3_blob *);
Returns the size in bytes of the BLOB accessible via thesuccessfully opened BLOB handle in its only argument. Theincremental blob I/O routines can only read or overwriting existingblob content; they cannot change the size of a blob.
This routine only works on a BLOB handle which has been createdby a prior successful call to sqlite3_blob_open() and which has notbeen closed by sqlite3_blob_close(). Passing any other pointer into this routine results in undefined and probably undesirable behavior.
Close A BLOB Handleint sqlite3_blob_close(sqlite3_blob *);
Closes an open BLOB handle.
Closing a BLOB shall cause the current transaction to commitif there are no other BLOBs, no pending prepared statements, and thedatabase connection is in autocommit mode.If any writes were made to the BLOB, they might be held in cacheuntil the close operation if they will fit.
Closing the BLOB often forces the changesout to disk and so if any I/O errors occur, they will likely occurat the time when the BLOB is closed. Any errors that occur duringclosing are reported as a non-zero return value.
The BLOB is closed unconditionally. Even if this routine returnsan error code, the BLOB is still closed.
Calling this routine with a null pointer (such as would be returnedby a failed call to sqlite3_blob_open()) is a harmless no-op.
Open A BLOB For Incremental I/Oint sqlite3_blob_open( sqlite3*, const char *zDb, const char *zTable, const char *zColumn, sqlite3_int64 iRow, int flags, sqlite3_blob **ppBlob);
This interfaces opens a handle to the BLOB locatedin row iRow, column zColumn, table zTable in database zDb;in other words, the same BLOB that would be selected by:
SELECT zColumn FROM zDb.zTable WHERE rowid = iRow;
If the flags parameter is non-zero, then the BLOB is opened for readand write access. If it is zero, the BLOB is opened for read access.It is not possible to open a column that is part of an index or primarykey for writing. If foreign key constraints are enabled, it isnot possible to open a column that is part of a child key for writing.
Note that the database name is not the filename that containsthe database but rather the symbolic name of the database thatappears after the AS keyword when the database is connected using ATTACH.For the main database file, the database name is "main".For TEMP tables, the database name is "temp".
On success, SQLITE_OK is returned and the new BLOB handle is writtento *ppBlob. Otherwise an error code is returned and *ppBlob is setto be a null pointer.This function sets the database connection error code and messageaccessible via sqlite3_errcode() and sqlite3_errmsg() and relatedfunctions. Note that the *ppBlob variable is always initialized in away that makes it safe to invoke sqlite3_blob_close() on *ppBlobregardless of the success or failure of this routine.
If the row that a BLOB handle points to is modified by anUPDATE, DELETE, or by ON CONFLICT side-effectsthen the BLOB handle is marked as "expired".This is true if any column of the row is changed, even a columnother than the one the BLOB handle is open on.Calls to sqlite3_blob_read() and sqlite3_blob_write() foran expired BLOB handle fail with a return code of SQLITE_ABORT.Changes written into a BLOB prior to the BLOB expiring are notrolled back by the expiration of the BLOB. Such changes will eventuallycommit if the transaction continues to completion.
Use the sqlite3_blob_bytes() interface to determine the size ofthe opened blob. The size of a blob may not be changed by thisinterface. Use the UPDATE SQL command to change the size of ablob.
The sqlite3_bind_zeroblob() and sqlite3_result_zeroblob() interfacesand the built-in zeroblob SQL function can be used, if desired,to create an empty, zero-filled blob in which to read or write usingthis interface.
To avoid a resource leak, every open BLOB handle should eventuallybe released by a call to sqlite3_blob_close().
Read Data From A BLOB Incrementallyint sqlite3_blob_read(sqlite3_blob *, void *Z, int N, int iOffset);
This function is used to read data from an open BLOB handle into acaller-supplied buffer. N bytes of data are copied into buffer Zfrom the open BLOB, starting at offset iOffset.
If offset iOffset is less than N bytes from the end of the BLOB,SQLITE_ERROR is returned and no data is read. If N or iOffset isless than zero, SQLITE_ERROR is returned and no data is read.The size of the blob (and hence the maximum value of N+iOffset)can be determined using the sqlite3_blob_bytes() interface.
An attempt to read from an expired BLOB handle fails with anerror code of SQLITE_ABORT.
On success, sqlite3_blob_read() returns SQLITE_OK.Otherwise, an error code or an extended error code is returned.
This routine only works on a BLOB handle which has been createdby a prior successful call to sqlite3_blob_open() and which has notbeen closed by sqlite3_blob_close(). Passing any other pointer into this routine results in undefined and probably undesirable behavior.
See also: sqlite3_blob_write().
Move a BLOB Handle to a New Rowint sqlite3_blob_reopen(sqlite3_blob *, sqlite3_int64);
This function is used to move an existing blob handle so that it pointsto a different row of the same database table. The new row is identifiedby the rowid value passed as the second argument. Only the row can bechanged. The database, table and column on which the blob handle is openremain the same. Moving an existing blob handle to a new row can befaster than closing the existing handle and opening a new one.
The new row must meet the same criteria as for sqlite3_blob_open() -it must exist and there must be either a blob or text value stored inthe nominated column. If the new row is not present in the table, or ifit does not contain a blob or text value, or if another error occurs, anSQLite error code is returned and the blob handle is considered aborted.All subsequent calls to sqlite3_blob_read(), sqlite3_blob_write() orsqlite3_blob_reopen() on an aborted blob handle immediately returnSQLITE_ABORT. Calling sqlite3_blob_bytes() on an aborted blob handlealways returns zero.
This function sets the database handle error code and message.
Write Data Into A BLOB Incrementallyint sqlite3_blob_write(sqlite3_blob *, const void *z, int n, int iOffset);
This function is used to write data into an open BLOB handle from acaller-supplied buffer. N bytes of data are copied from the buffer Zinto the open BLOB, starting at offset iOffset.
If the BLOB handle passed as the first argument was not opened forwriting (the flags parameter to sqlite3_blob_open() was zero),this function returns SQLITE_READONLY.
This function may only modify the contents of the BLOB; it isnot possible to increase the size of a BLOB using this API.If offset iOffset is less than N bytes from the end of the BLOB,SQLITE_ERROR is returned and no data is written. If N isless than zero SQLITE_ERROR is returned and no data is written.The size of the BLOB (and hence the maximum value of N+iOffset)can be determined using the sqlite3_blob_bytes() interface.
An attempt to write to an expired BLOB handle fails with anerror code of SQLITE_ABORT. Writes to the BLOB that occurredbefore the BLOB handle expired are not rolled back by theexpiration of the handle, though of course those changes mighthave been overwritten by the statement that expired the BLOB handleor by other independent statements.
On success, sqlite3_blob_write() returns SQLITE_OK.Otherwise, an error code or an extended error code is returned.
This routine only works on a BLOB handle which has been createdby a prior successful call to sqlite3_blob_open() and which has notbeen closed by sqlite3_blob_close(). Passing any other pointer into this routine results in undefined and probably undesirable behavior.
See also: sqlite3_blob_read().
Register A Callback To Handle SQLITE_BUSY Errorsint sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*);
This routine sets a callback function that might be invoked wheneveran attempt is made to open a database table that another threador process has locked.
If the busy callback is NULL, then SQLITE_BUSY or SQLITE_IOERR_BLOCKEDis returned immediately upon encountering the lock. If the busy callbackis not NULL, then the callback might be invoked with two arguments.
The first argument to the busy handler is a copy of the void* pointer whichis the third argument to sqlite3_busy_handler(). The second argument tothe busy handler callback is the number of times that the busy handler hasbeen invoked for this locking event. If thebusy callback returns 0, then no additional attempts are made toaccess the database and SQLITE_BUSY or SQLITE_IOERR_BLOCKED is returned.If the callback returns non-zero, then another attemptis made to open the database for reading and the cycle repeats.
The presence of a busy handler does not guarantee that it will be invokedwhen there is lock contention. If SQLite determines that invoking the busyhandler could result in a deadlock, it will go ahead and return SQLITE_BUSYor SQLITE_IOERR_BLOCKED instead of invoking the busy handler.Consider a scenario where one process is holding a read lock thatit is trying to promote to a reserved lock anda second process is holding a reserved lock that it is tryingto promote to an exclusive lock. The first process cannot proceedbecause it is blocked by the second and the second process cannotproceed because it is blocked by the first. If both processesinvoke the busy handlers, neither will make any progress. Therefore,SQLite returns SQLITE_BUSY for the first process, hoping that thiswill induce the first process to release its read lock and allowthe second process to proceed.
The default busy callback is NULL.
The SQLITE_BUSY error is converted to SQLITE_IOERR_BLOCKEDwhen SQLite is in the middle of a large transaction where all thechanges will not fit into the in-memory cache. SQLite willalready hold a RESERVED lock on the database file, but it needsto promote this lock to EXCLUSIVE so that it can spill cachepages into the database file without harm to concurrentreaders. If it is unable to promote the lock, then the in-memorycache will be left in an inconsistent state and so the errorcode is promoted from the relatively benign SQLITE_BUSY tothe more severe SQLITE_IOERR_BLOCKED. This error code promotionforces an automatic rollback of the changes. See theCorruptionFollowingBusyError wiki page for a discussion of whythis is important.
There can only be a single busy handler defined for eachdatabase connection. Setting a new busy handler clears anypreviously set handler. Note that calling sqlite3_busy_timeout()will also set or clear the busy handler.
The busy callback should not take any actions which modify thedatabase connection that invoked the busy handler. Any such actionsresult in undefined behavior.
A busy handler must not close the database connectionor prepared statement that invoked the busy handler.
Set A Busy Timeoutint sqlite3_busy_timeout(sqlite3*, int ms);
This routine sets a busy handler that sleepsfor a specified amount of time when a table is locked. The handlerwill sleep multiple times until at least "ms" milliseconds of sleepinghave accumulated. After at least "ms" milliseconds of sleeping,the handler returns 0 which causes sqlite3_step() to returnSQLITE_BUSY or SQLITE_IOERR_BLOCKED.
Calling this routine with an argument less than or equal to zeroturns off all busy handlers.
There can only be a single busy handler for a particulardatabase connection any any given moment. If another busy handlerwas defined (using sqlite3_busy_handler()) prior to callingthis routine, that other busy handler is cleared.
Count The Number Of Rows Modifiedint sqlite3_changes(sqlite3*);
This function returns the number of database rows that were changedor inserted or deleted by the most recently completed SQL statementon the database connection specified by the first parameter.Only changes that are directly specified by the INSERT, UPDATE,or DELETE statement are counted. Auxiliary changes caused bytriggers or foreign key actions are not counted. Use thesqlite3_total_changes() function to find the total number of changesincluding changes caused by triggers and foreign key actions.
Changes to a view that are simulated by an INSTEAD OF triggerare not counted. Only real table changes are counted.
A "row change" is a change to a single row of a single tablecaused by an INSERT, DELETE, or UPDATE statement. Rows thatare changed as side effects of REPLACE constraint resolution,rollback, ABORT processing, DROP TABLE, or by any othermechanisms do not count as direct row changes.
A "trigger context" is a scope of execution that begins andends with the script of a trigger.Most SQL statements areevaluated outside of any trigger. This is the "top level"trigger context. If a trigger fires from the top level, anew trigger context is entered for the duration of that onetrigger. Subtriggers create subcontexts for their duration.
Calling sqlite3_exec() or sqlite3_step() recursively doesnot create a new trigger context.
This function returns the number of direct row changes in themost recent INSERT, UPDATE, or DELETE statement within the sametrigger context.
Thus, when called from the top level, this function returns thenumber of changes in the most recent INSERT, UPDATE, or DELETEthat also occurred at the top level. Within the body of a trigger,the sqlite3_changes() interface can be called to find the number ofchanges in the most recently completed INSERT, UPDATE, or DELETEstatement within the body of the same trigger.However, the number returned does not include changescaused by subtriggers since those have their own context.
See also the sqlite3_total_changes() interface, thecount_changes pragma, and the changes() SQL function.
If a separate thread makes changes on the same database connectionwhile sqlite3_changes() is running then the value returnedis unpredictable and not meaningful.
Reset All Bindings On A Prepared Statementint sqlite3_clear_bindings(sqlite3_stmt*);
Contrary to the intuition of many, sqlite3_reset() does not resetthe bindings on a prepared statement.Use this routine to reset all host parameters to NULL.
Closing A Database Connectionint sqlite3_close(sqlite3 *);
The sqlite3_close() routine is the destructor for the sqlite3 object.Calls to sqlite3_close() return SQLITE_OK if the sqlite3 object issuccessfully destroyed and all associated resources are deallocated.
Applications must finalize all prepared statementsand close all BLOB handles associated withthe sqlite3 object prior to attempting to close the object. Ifsqlite3_close() is called on a database connection that still hasoutstanding prepared statements or BLOB handles, then it returnsSQLITE_BUSY.
If sqlite3_close() is invoked while a transaction is open,the transaction is automatically rolled back.
The C parameter to sqlite3_close(C) must be either a NULLpointer or an sqlite3 object pointer obtainedfrom sqlite3_open(), sqlite3_open16(), orsqlite3_open_v2(), and not previously closed.Calling sqlite3_close() with a NULL pointer argument is aharmless no-op.
Number Of Columns In A Result Setint sqlite3_column_count(sqlite3_stmt *pStmt);
Return the number of columns in the result set returned by theprepared statement. This routine returns 0 if pStmt is an SQLstatement that does not return data (for example an UPDATE).
See also: sqlite3_data_count()
Configuring The SQLite Libraryint sqlite3_config(int, ...);
The sqlite3_config() interface is used to make global configurationchanges to SQLite in order to tune SQLite to the specific needs ofthe application. The default configuration is recommended for mostapplications and so this routine is usually not necessary. It isprovided to support rare applications with unusual needs.
The sqlite3_config() interface is not threadsafe. The applicationmust insure that no other SQLite interfaces are invoked by otherthreads while sqlite3_config() is running. Furthermore, sqlite3_config()may only be invoked prior to library initialization usingsqlite3_initialize() or after shutdown by sqlite3_shutdown().If sqlite3_config() is called after sqlite3_initialize() and beforesqlite3_shutdown() then it will return SQLITE_MISUSE.Note, however, that sqlite3_config() can be called as part of theimplementation of an application-defined sqlite3_os_init().
The first argument to sqlite3_config() is an integerconfiguration option that determineswhat property of SQLite is to be configured. Subsequent argumentsvary depending on the configuration optionin the first argument.
When a configuration option is set, sqlite3_config() returns SQLITE_OK.If the option is unknown or SQLite is unable to set the optionthen this routine returns a non-zero error code.
Database Connection For Functionssqlite3 *sqlite3_context_db_handle(sqlite3_context*);
The sqlite3_context_db_handle() interface returns a copy ofthe pointer to the database connection (the 1st parameter)of the sqlite3_create_function()and sqlite3_create_function16() routines that originallyregistered the application defined function.
Number of columns in a result setint sqlite3_data_count(sqlite3_stmt *pStmt);
The sqlite3_data_count(P) interface returns the number of columns in thecurrent row of the result set of prepared statement P.If prepared statement P does not have results ready to return(via calls to the sqlite3_column_*() ofinterfaces) then sqlite3_data_count(P) returns 0.The sqlite3_data_count(P) routine also returns 0 if P is a NULL pointer.The sqlite3_data_count(P) routine returns 0 if the previous call tosqlite3_step(P) returned SQLITE_DONE. The sqlite3_data_count(P)will return non-zero if previous call to sqlite3_step(P) returnedSQLITE_ROW, except in the case of the PRAGMA incremental_vacuumwhere it always returns zero since each step of that multi-steppragma returns 0 columns of data.
See also: sqlite3_column_count()
Configure database connectionsint sqlite3_db_config(sqlite3*, int op, ...);
The sqlite3_db_config() interface is used to make configurationchanges to a database connection. The interface is similar tosqlite3_config() except that the changes apply to a singledatabase connection (specified in the first argument).
The second argument to sqlite3_db_config(D,V,...) is theconfiguration verb - an integer codethat indicates what aspect of the database connection is being configured.Subsequent arguments vary depending on the configuration verb.
Calls to sqlite3_db_config() return SQLITE_OK if and only ifthe call is considered successful.
Return The Filename For A Database Connectionconst char *sqlite3_db_filename(sqlite3 *db, const char *zDbName);
The sqlite3_db_filename(D,N) interface returns a pointer to a filenameassociated with database N of connection D. The main database filehas the name "main". If there is no attached database N on the databaseconnection D, or if database N is a temporary or in-memory database, thena NULL pointer is returned.
The filename returned by this function is the output of thexFullPathname method of the VFS. In other words, the filenamewill be an absolute pathname, even if the filename usedto open the database originally was a URI or relative pathname.
Find The Database Handle Of A Prepared Statementsqlite3 *sqlite3_db_handle(sqlite3_stmt*);
The sqlite3_db_handle interface returns the database connection handleto which a prepared statement belongs. The database connectionreturned by sqlite3_db_handle is the same database connectionthat was the first argumentto the sqlite3_prepare_v2() call (or its variants) that was used tocreate the statement in the first place.
Retrieve the mutex for a database connectionsqlite3_mutex *sqlite3_db_mutex(sqlite3*);
This interface returns a pointer the sqlite3_mutex object thatserializes access to the database connection given in the argumentwhen the threading mode is Serialized.If the threading mode is Single-thread or Multi-thread then thisroutine returns a NULL pointer.
Free Memory Used By A Database Connectionint sqlite3_db_release_memory(sqlite3*);
The sqlite3_db_release_memory(D) interface attempts to free as much heapmemory as possible from database connection D. Unlike thesqlite3_release_memory() interface, this interface is effect evenwhen then SQLITE_ENABLE_MEMORY_MANAGEMENT compile-time option isomitted.
See also: sqlite3_release_memory()
Database Connection Statusint sqlite3_db_status(sqlite3*, int op, int *pCur, int *pHiwtr, int resetFlg);
This interface is used to retrieve runtime status informationabout a single database connection. The first argument is thedatabase connection object to be interrogated. The second argumentis an integer constant, taken from the set ofSQLITE_DBSTATUS options, thatdetermines the parameter to interrogate. The set ofSQLITE_DBSTATUS options is likelyto grow in future releases of SQLite.
The current value of the requested parameter is written into *pCurand the highest instantaneous value is written into *pHiwtr. Ifthe resetFlg is true, then the highest instantaneous value isreset back down to the current value.
The sqlite3_db_status() routine returns SQLITE_OK on success and anon-zero error code on failure.
See also: sqlite3_status() and sqlite3_stmt_status().
Declare The Schema Of A Virtual Tableint sqlite3_declare_vtab(sqlite3*, const char *zSQL);
The xCreate and xConnect methods of avirtual table module call this interfaceto declare the format (the names and datatypes of the columns) ofthe virtual tables they implement.
Enable Or Disable Extension Loadingint sqlite3_enable_load_extension(sqlite3 *db, int onoff);
So as not to open security holes in older applications that areunprepared to deal with extension loading, and as a means of disablingextension loading while evaluating user-entered SQL, the following APIis provided to turn the sqlite3_load_extension() mechanism on and off.
Extension loading is off by default. See ticket #1863.Call the sqlite3_enable_load_extension() routine with onoff==1to turn extension loading on and call it with onoff==0 to turnit back off again.
One-Step Query Execution Interfaceint sqlite3_exec( sqlite3*, /* An open database */ const char *sql, /* SQL to be evaluated */ int (*callback)(void*,int,char**,char**), /* Callback function */ void *, /* 1st argument to callback */ char **errmsg /* Error msg written here */);
The sqlite3_exec() interface is a convenience wrapper aroundsqlite3_prepare_v2(), sqlite3_step(), and sqlite3_finalize(),that allows an application to run multiple statements of SQLwithout having to use a lot of C code.
The sqlite3_exec() interface runs zero or more UTF-8 encoded,semicolon-separate SQL statements passed into its 2nd argument,in the context of the database connection passed in as its 1stargument. If the callback function of the 3rd argument tosqlite3_exec() is not NULL, then it is invoked for each result rowcoming out of the evaluated SQL statements. The 4th argument tosqlite3_exec() is relayed through to the 1st argument of eachcallback invocation. If the callback pointer to sqlite3_exec()is NULL, then no callback is ever invoked and result rows areignored.
If an error occurs while evaluating the SQL statements passed intosqlite3_exec(), then execution of the current statement stops andsubsequent statements are skipped. If the 5th parameter to sqlite3_exec()is not NULL then any error message is written into memory obtainedfrom sqlite3_malloc() and passed back through the 5th parameter.To avoid memory leaks, the application should invoke sqlite3_free()on error message strings returned through the 5th parameter ofof sqlite3_exec() after the error message string is no longer needed.If the 5th parameter to sqlite3_exec() is not NULL and no errorsoccur, then sqlite3_exec() sets the pointer in its 5th parameter toNULL before returning.
If an sqlite3_exec() callback returns non-zero, the sqlite3_exec()routine returns SQLITE_ABORT without invoking the callback again andwithout running any subsequent SQL statements.
The 2nd argument to the sqlite3_exec() callback function is thenumber of columns in the result. The 3rd argument to the sqlite3_exec()callback is an array of pointers to strings obtained as if fromsqlite3_column_text(), one for each column. If an element of aresult row is NULL then the corresponding string pointer for thesqlite3_exec() callback is a NULL pointer. The 4th argument to thesqlite3_exec() callback is an array of pointers to strings where eachentry represents the name of corresponding result column as obtainedfrom sqlite3_column_name().
If the 2nd parameter to sqlite3_exec() is a NULL pointer, a pointerto an empty string, or a pointer that contains only whitespace and/orSQL comments, then no SQL statements are evaluated and the databaseis not changed.
Restrictions:
The application must insure that the 1st parameter to sqlite3_exec()is a valid and open database connection. The application must not close database connection specified bythe 1st parameter to sqlite3_exec() while sqlite3_exec() is running. The application must not modify the SQL statement text passed intothe 2nd parameter of sqlite3_exec() while sqlite3_exec() is running.Enable Or Disable Extended Result Codesint sqlite3_extended_result_codes(sqlite3*, int onoff);
The sqlite3_extended_result_codes() routine enables or disables theextended result codes feature of SQLite. The extended resultcodes are disabled by default for historical compatibility.
Low-Level Control Of Database Filesint sqlite3_file_control(sqlite3*, const char *zDbName, int op, void*);
The sqlite3_file_control() interface makes a direct call to thexFileControl method for the sqlite3_io_methods object associatedwith a particular database identified by the second argument. Thename of the database is "main" for the main database or "temp" for theTEMP database, or the name that appears after the AS keyword fordatabases that are added using the ATTACH SQL command.A NULL pointer can be used in place of "main" to refer to themain database file.The third and fourth parameters to this routineare passed directly through to the second and third parameters ofthe xFileControl method. The return value of the xFileControlmethod becomes the return value of this routine.
The SQLITE_FCNTL_FILE_POINTER value for the op parameter causesa pointer to the underlying sqlite3_file object to be written intothe space pointed to by the 4th parameter. The SQLITE_FCNTL_FILE_POINTERcase is a short-circuit path which does not actually invoke theunderlying sqlite3_io_methods.xFileControl method.
If the second parameter (zDbName) does not match the name of anyopen database file, then SQLITE_ERROR is returned. This errorcode is not remembered and will not be recalled by sqlite3_errcode()or sqlite3_errmsg(). The underlying xFileControl method mightalso return SQLITE_ERROR. There is no way to distinguish betweenan incorrect zDbName and an SQLITE_ERROR return from the underlyingxFileControl method.
See also: SQLITE_FCNTL_LOCKSTATE
Destroy A Prepared Statement Objectint sqlite3_finalize(sqlite3_stmt *pStmt);
The sqlite3_finalize() function is called to delete a prepared statement.If the most recent evaluation of the statement encountered no errorsor if the statement is never been evaluated, then sqlite3_finalize() returnsSQLITE_OK. If the most recent evaluation of statement S failed, thensqlite3_finalize(S) returns the appropriate error code orextended error code.
The sqlite3_finalize(S) routine can be called at any point duringthe life cycle of prepared statement S:before statement S is ever evaluated, afterone or more calls to sqlite3_reset(), or after any callto sqlite3_step() regardless of whether or not the statement hascompleted execution.
Invoking sqlite3_finalize() on a NULL pointer is a harmless no-op.
The application must finalize every prepared statement in order to avoidresource leaks. It is a grievous error for the application to try to usea prepared statement after it has been finalized. Any use of a preparedstatement after it has been finalized can result in undefined andundesirable behavior such as segfaults and heap corruption.
Interrupt A Long-Running Queryvoid sqlite3_interrupt(sqlite3*);
This function causes any pending database operation to abort andreturn at its earliest opportunity. This routine is typicallycalled in response to a user action such as pressing "Cancel"or Ctrl-C where the user wants a long query operation to haltimmediately.
It is safe to call this routine from a thread different from thethread that is currently running the database operation. But itis not safe to call this routine with a database connection thatis closed or might close before sqlite3_interrupt() returns.
If an SQL operation is very nearly finished at the time whensqlite3_interrupt() is called, then it might not have an opportunityto be interrupted and might continue to completion.
An SQL operation that is interrupted will return SQLITE_INTERRUPT.If the interrupted SQL operation is an INSERT, UPDATE, or DELETEthat is inside an explicit transaction, then the entire transactionwill be rolled back automatically.
The sqlite3_interrupt(D) call is in effect until all currently runningSQL statements on database connection D complete. Any new SQL statementsthat are started after the sqlite3_interrupt() call and before therunning statements reaches zero are interrupted as if they had beenrunning prior to the sqlite3_interrupt() call. New SQL statementsthat are started after the running statement count reaches zero arenot effected by the sqlite3_interrupt().A call to sqlite3_interrupt(D) that occurs when there are no runningSQL statements is a no-op and has no effect on SQL statementsthat are started after the sqlite3_interrupt() call returns.
If the database connection closes while sqlite3_interrupt()is running then bad things will likely happen.
Last Insert Rowidsqlite3_int64 sqlite3_last_insert_rowid(sqlite3*);
Each entry in an SQLite table has a unique 64-bit signedinteger key called the "rowid". The rowid is always availableas an undeclared column named ROWID, OID, or _ROWID_ as long as thosenames are not also used by explicitly declared columns. Ifthe table has a column of type INTEGER PRIMARY KEY then that columnis another alias for the rowid.
This routine returns the rowid of the most recentsuccessful INSERT into the database from the database connectionin the first argument. As of SQLite version 3.7.7, this routinesrecords the last insert rowid of both ordinary tables and virtual tables.If no successful INSERTshave ever occurred on that database connection, zero is returned.
If an INSERT occurs within a trigger or within a virtual tablemethod, then this routine will return the rowid of the insertedrow as long as the trigger or virtual table method is running.But once the trigger or virtual table method ends, the value returnedby this routine reverts to what it was before the trigger or virtualtable method began.
An INSERT that fails due to a constraint violation is not asuccessful INSERT and does not change the value returned by thisroutine. Thus INSERT OR FAIL, INSERT OR IGNORE, INSERT OR ROLLBACK,and INSERT OR ABORT make no changes to the return value of thisroutine when their insertion fails. When INSERT OR REPLACEencounters a constraint violation, it does not fail. TheINSERT continues to completion after deleting rows that causedthe constraint problem so INSERT OR REPLACE will always changethe return value of this interface.
For the purposes of this routine, an INSERT is considered tobe successful even if it is subsequently rolled back.
This function is accessible to SQL statements via thelast_insert_rowid() SQL function.
If a separate thread performs a new INSERT on the samedatabase connection while the sqlite3_last_insert_rowid()function is running and thus changes the last insert rowid,then the value returned by sqlite3_last_insert_rowid() isunpredictable and might not equal either the old or the newlast insert rowid.
Run-time Limitsint sqlite3_limit(sqlite3*, int id, int newVal);
This interface allows the size of various constructs to be limitedon a connection by connection basis. The first parameter is thedatabase connection whose limit is to be set or queried. Thesecond parameter is one of the limit categories that define aclass of constructs to be size limited. The third parameter is thenew limit for that construct.
If the new limit is a negative number, the limit is unchanged.For each limit category SQLITE_LIMIT_NAME there is ahard upper boundset at compile-time by a C preprocessor macro calledSQLITE_MAX_NAME.(The "_LIMIT_" in the name is changed to "_MAX_".)Attempts to increase a limit above its hard upper bound aresilently truncated to the hard upper bound.
Regardless of whether or not the limit was changed, thesqlite3_limit() interface returns the prior value of the limit.Hence, to find the current value of a limit without changing it,simply invoke this interface with the third parameter set to -1.
Run-time limits are intended for use in applications that manageboth their own internal database and also databases that are controlledby untrusted external sources. An example application might be aweb browser that has its own databases for storing history andseparate databases controlled by JavaScript applications downloadedoff the Internet. The internal databases can be given thelarge, default limits. Databases managed by external sources canbe given much smaller limits designed to prevent a denial of serviceattack. Developers might also want to use the sqlite3_set_authorizer()interface to further control untrusted SQL. The size of the databasecreated by an untrusted script can be contained using themax_page_count PRAGMA.
New run-time limit categories may be added in future releases.
Load An Extensionint sqlite3_load_extension( sqlite3 *db, /* Load the extension into this database connection */ const char *zFile, /* Name of the shared library containing extension */ const char *zProc, /* Entry point. Derived from zFile if 0 */ char **pzErrMsg /* Put error message here if not 0 */);
This interface loads an SQLite extension library from the named file.
The sqlite3_load_extension() interface attempts to load anSQLite extension library contained in the file zFile.
The entry point is zProc.zProc may be 0, in which case the name of the entry pointdefaults to "sqlite3_extension_init".The sqlite3_load_extension() interface returnsSQLITE_OK on success and SQLITE_ERROR if something goes wrong.If an error occurs and pzErrMsg is not 0, then thesqlite3_load_extension() interface shall attempt tofill *pzErrMsg with error message text stored in memoryobtained from sqlite3_malloc(). The calling functionshould free this memory by calling sqlite3_free().
Extension loading must be enabled usingsqlite3_enable_load_extension() prior to calling this API,otherwise an error will be returned.
See also the load_extension() SQL function.
Error Logging Interfacevoid sqlite3_log(int iErrCode, const char *zFormat, ...);
The sqlite3_log() interface writes a message into the error logestablished by the SQLITE_CONFIG_LOG option to sqlite3_config().If logging is enabled, the zFormat string and subsequent arguments areused with sqlite3_snprintf() to generate the final output string.
The sqlite3_log() interface is intended for use by extensions such asvirtual tables, collating functions, and SQL functions. While there isnothing to prevent an application from calling sqlite3_log(), doing sois considered bad form.
The zFormat string must not be NULL.
To avoid deadlocks and other threading problems, the sqlite3_log() routinewill not use dynamically allocated memory. The log message is stored ina fixed-length buffer on the stack. If the log message is longer thana few hundred characters, it will be truncated to the length of thebuffer.
Find the next prepared statementsqlite3_stmt *sqlite3_next_stmt(sqlite3 *pDb, sqlite3_stmt *pStmt);
This interface returns a pointer to the next prepared statement afterpStmt associated with the database connection pDb. If pStmt is NULLthen this interface returns a pointer to the first prepared statementassociated with the database connection pDb. If no prepared statementsatisfies the conditions of this routine, it returns NULL.
The database connection pointer D in a call tosqlite3_next_stmt(D,S) must refer to an open databaseconnection and in particular must not be a NULL pointer.
Overload A Function For A Virtual Tableint sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg);
Virtual tables can provide alternative implementations of functionsusing the xFindFunction method of the virtual table module.But global versions of those functionsmust exist in order to be overloaded.
This API makes sure a global version of a function with a particularname and number of parameters exists. If no such function existsbefore this API is called, a new function is created. The implementationof the new function always causes an exception to be thrown. Sothe new function is not good for anything by itself. Its onlypurpose is to be a placeholder function that can be overloadedby a virtual table.
Query Progress Callbacksvoid sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
The sqlite3_progress_handler(D,N,X,P) interface causes the callbackfunction X to be invoked periodically during long running calls tosqlite3_exec(), sqlite3_step() and sqlite3_get_table() fordatabase connection D. An example use for thisinterface is to keep a GUI updated during a large query.
The parameter P is passed through as the only parameter to thecallback function X. The parameter N is the number ofvirtual machine instructions that are evaluated between successiveinvocations of the callback X.
Only a single progress handler may be defined at one time perdatabase connection; setting a new progress handler cancels theold one. Setting parameter X to NULL disables the progress handler.The progress handler is also disabled by setting N to a value lessthan 1.
If the progress callback returns non-zero, the operation isinterrupted. This feature can be used to implement a"Cancel" button on a GUI progress dialog box.
The progress handler callback must not do anything that will modifythe database connection that invoked the progress handler.Note that sqlite3_prepare_v2() and sqlite3_step() both modify theirdatabase connections for the meaning of "modify" in this paragraph.
Pseudo-Random Number Generatorvoid sqlite3_randomness(int N, void *P);
SQLite contains a high-quality pseudo-random number generator (PRNG) used toselect random ROWIDs when inserting new records into a table thatalready uses the largest possible ROWID. The PRNG is also used forthe build-in random() and randomblob() SQL functions. This interface allowsapplications to access the same PRNG for other purposes.
A call to this routine stores N bytes of randomness into buffer P.
The first time this routine is invoked (either internally or bythe application) the PRNG is seeded using randomness obtainedfrom the xRandomness method of the default sqlite3_vfs object.On all subsequent invocations, the pseudo-randomness is generatedinternally and without recourse to the sqlite3_vfs xRandomnessmethod.
Attempt To Free Heap Memoryint sqlite3_release_memory(int);
The sqlite3_release_memory() interface attempts to free N bytesof heap memory by deallocating non-essential memory allocationsheld by the database library. Memory used to cache databasepages to improve performance is an example of non-essential memory.sqlite3_release_memory() returns the number of bytes actually freed,which might be more or less than the amount requested.The sqlite3_release_memory() routine is a no-op returning zeroif SQLite is not compiled with SQLITE_ENABLE_MEMORY_MANAGEMENT.
See also: sqlite3_db_release_memory()
Reset A Prepared Statement Objectint sqlite3_reset(sqlite3_stmt *pStmt);
The sqlite3_reset() function is called to reset a prepared statementobject back to its initial state, ready to be re-executed.Any SQL statement variables that had values bound to them usingthe sqlite3_bind_*() API retain their values.Use sqlite3_clear_bindings() to reset the bindings.
The sqlite3_reset(S) interface resets the prepared statement Sback to the beginning of its program.
If the most recent call to sqlite3_step(S) for theprepared statement S returned SQLITE_ROW or SQLITE_DONE,or if sqlite3_step(S) has never before been called on S,then sqlite3_reset(S) returns SQLITE_OK.
If the most recent call to sqlite3_step(S) for theprepared statement S indicated an error, thensqlite3_reset(S) returns an appropriate error code.
The sqlite3_reset(S) interface does not change the valuesof any bindings on the prepared statement S.
Reset Automatic Extension Loadingvoid sqlite3_reset_auto_extension(void);
This interface disables all automatic extensions previouslyregistered using sqlite3_auto_extension().
Compile-Time Authorization Callbacksint sqlite3_set_authorizer( sqlite3*, int (*xAuth)(void*,int,const char*,const char*,const char*,const char*), void *pUserData);
This routine registers an authorizer callback with a particulardatabase connection, supplied in the first argument.The authorizer callback is invoked as SQL statements are being compiledby sqlite3_prepare() or its variants sqlite3_prepare_v2(),sqlite3_prepare16() and sqlite3_prepare16_v2(). At variouspoints during the compilation process, as logic is being createdto perform various actions, the authorizer callback is invoked tosee if those actions are allowed. The authorizer callback shouldreturn SQLITE_OK to allow the action, SQLITE_IGNORE to disallow thespecific action but allow the SQL statement to continue to becompiled, or SQLITE_DENY to cause the entire SQL statement to berejected with an error. If the authorizer callback returnsany value other than SQLITE_IGNORE, SQLITE_OK, or SQLITE_DENYthen the sqlite3_prepare_v2() or equivalent call that triggeredthe authorizer will fail with an error message.
When the callback returns SQLITE_OK, that means the operationrequested is ok. When the callback returns SQLITE_DENY, thesqlite3_prepare_v2() or equivalent call that triggered theauthorizer will fail with an error message explaining thataccess is denied.
The first parameter to the authorizer callback is a copy of the thirdparameter to the sqlite3_set_authorizer() interface. The second parameterto the callback is an integer action code that specifiesthe particular action to be authorized. The third through sixth parametersto the callback are zero-terminated strings that contain additionaldetails about the action to be authorized.
If the action code is SQLITE_READand the callback returns SQLITE_IGNORE then theprepared statement statement is constructed to substitutea NULL value in place of the table column that would havebeen read if SQLITE_OK had been returned. The SQLITE_IGNOREreturn can be used to deny an untrusted user access to individualcolumns of a table.If the action code is SQLITE_DELETE and the callback returnsSQLITE_IGNORE then the DELETE operation proceeds but thetruncate optimization is disabled and all rows are deleted individually.
An authorizer is used when preparingSQL statements from an untrusted source, to ensure that the SQL statementsdo not try to access data they are not allowed to see, or that they do nottry to execute malicious statements that damage the database. Forexample, an application may allow a user to enter arbitrarySQL queries for evaluation by a database. But the application doesnot want the user to be able to make arbitrary changes to thedatabase. An authorizer could then be put in place while theuser-entered SQL is being prepared thatdisallows everything except SELECT statements.
Applications that need to process SQL from untrusted sourcesmight also consider lowering resource limits using sqlite3_limit()and limiting database size using the max_page_count PRAGMAin addition to using an authorizer.
Only a single authorizer can be in place on a database connectionat a time. Each call to sqlite3_set_authorizer overrides theprevious call. Disable the authorizer by installing a NULL callback.The authorizer is disabled by default.
The authorizer callback must not do anything that will modifythe database connection that invoked the authorizer callback.Note that sqlite3_prepare_v2() and sqlite3_step() both modify theirdatabase connections for the meaning of "modify" in this paragraph.
When sqlite3_prepare_v2() is used to prepare a statement, thestatement might be re-prepared during sqlite3_step() due to aschema change. Hence, the application should ensure that thecorrect authorizer callback remains in place during the sqlite3_step().
Note that the authorizer callback is invoked only duringsqlite3_prepare() or its variants. Authorization is notperformed during statement evaluation in sqlite3_step(), unlessas stated in the previous paragraph, sqlite3_step() invokessqlite3_prepare_v2() to reprepare a statement after a schema change.
Suspend Execution For A Short Timeint sqlite3_sleep(int);
The sqlite3_sleep() function causes the current thread to suspend executionfor at least a number of milliseconds specified in its parameter.
If the operating system does not support sleep requests withmillisecond time resolution, then the time will be rounded up tothe nearest second. The number of milliseconds of sleep actuallyrequested from the operating system is returned.
SQLite implements this interface by calling the xSleep()method of the default sqlite3_vfs object. If the xSleep() methodof the default VFS is not implemented correctly, or not implemented atall, then the behavior of sqlite3_sleep() may deviate from the descriptionin the previous paragraphs.
Deprecated Soft Heap Limit Interfacevoid sqlite3_soft_heap_limit(int N);
This is a deprecated version of the sqlite3_soft_heap_limit64()interface. This routine is provided for historical compatibilityonly. All new applications should use thesqlite3_soft_heap_limit64() interface rather than this one.
Impose A Limit On Heap Sizesqlite3_int64 sqlite3_soft_heap_limit64(sqlite3_int64 N);
The sqlite3_soft_heap_limit64() interface sets and/or queries thesoft limit on the amount of heap memory that may be allocated by SQLite.SQLite strives to keep heap memory utilization below the soft heaplimit by reducing the number of pages held in the page cacheas heap memory usages approaches the limit.The soft heap limit is "soft" because even though SQLite strives to staybelow the limit, it will exceed the limit rather than generatean SQLITE_NOMEM error. In other words, the soft heap limitis advisory only.
The return value from sqlite3_soft_heap_limit64() is the size ofthe soft heap limit prior to the call, or negative in the case of anerror. If the argument N is negativethen no change is made to the soft heap limit. Hence, the currentsize of the soft heap limit can be determined by invokingsqlite3_soft_heap_limit64() with a negative argument.
If the argument N is zero then the soft heap limit is disabled.
The soft heap limit is not enforced in the current implementationif one or more of following conditions are true:
The soft heap limit is set to zero. Memory accounting is disabled using a combination of thesqlite3_config(SQLITE_CONFIG_MEMSTATUS,...) start-time option andthe SQLITE_DEFAULT_MEMSTATUS compile-time option. An alternative page cache implementation is specified usingsqlite3_config(SQLITE_CONFIG_PCACHE2,...). The page cache allocates from its own memory pool suppliedby sqlite3_config(SQLITE_CONFIG_PAGECACHE,...) rather thanfrom the heap.Beginning with SQLite version 3.7.3, the soft heap limit is enforcedregardless of whether or not the SQLITE_ENABLE_MEMORY_MANAGEMENTcompile-time option is invoked. With SQLITE_ENABLE_MEMORY_MANAGEMENT,the soft heap limit is enforced on every memory allocation. WithoutSQLITE_ENABLE_MEMORY_MANAGEMENT, the soft heap limit is only enforcedwhen memory is allocated by the page cache. Testing suggests that becausethe page cache is the predominate memory user in SQLite, mostapplications will achieve adequate soft heap limit enforcement withoutthe use of SQLITE_ENABLE_MEMORY_MANAGEMENT.
The circumstances under which SQLite will enforce the soft heap limit maychanges in future releases of SQLite.
Retrieving Statement SQLconst char *sqlite3_sql(sqlite3_stmt *pStmt);
This interface can be used to retrieve a saved copy of the originalSQL text used to create a prepared statement if that statement wascompiled using either sqlite3_prepare_v2() or sqlite3_prepare16_v2().
SQLite Runtime Statusint sqlite3_status(int op, int *pCurrent, int *pHighwater, int resetFlag);
This interface is used to retrieve runtime status informationabout the performance of SQLite, and optionally to reset varioushighwater marks. The first argument is an integer code forthe specific parameter to measure. Recognized integer codesare of the form SQLITE_STATUS_....The current value of the parameter is returned into *pCurrent.The highest recorded value is returned in *pHighwater. If theresetFlag is true, then the highest record value is reset after*pHighwater is written. Some parameters do not record the highestvalue. For those parametersnothing is written into *pHighwater and the resetFlag is ignored.Other parameters record only the highwater mark and not the currentvalue. For these latter parameters nothing is written into *pCurrent.
The sqlite3_status() routine returns SQLITE_OK on success and anon-zero error code on failure.
This routine is threadsafe but is not atomic. This routine can becalled while other threads are running the same or different SQLiteinterfaces. However the values returned in *pCurrent and*pHighwater reflect the status of SQLite at different points in timeand it is possible that another thread might change the parameterin between the times when *pCurrent and *pHighwater are written.
See also: sqlite3_db_status()
Evaluate An SQL Statementint sqlite3_step(sqlite3_stmt*);
After a prepared statement has been prepared using eithersqlite3_prepare_v2() or sqlite3_prepare16_v2() or one of the legacyinterfaces sqlite3_prepare() or sqlite3_prepare16(), this functionmust be called one or more times to evaluate the statement.
The details of the behavior of the sqlite3_step() interface dependon whether the statement was prepared using the newer "v2" interfacesqlite3_prepare_v2() and sqlite3_prepare16_v2() or the older legacyinterface sqlite3_prepare() and sqlite3_prepare16(). The use of thenew "v2" interface is recommended for new applications but the legacyinterface will continue to be supported.
In the legacy interface, the return value will be either SQLITE_BUSY,SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR, or SQLITE_MISUSE.With the "v2" interface, any of the other result codes orextended result codes might be returned as well.
SQLITE_BUSY means that the database engine was unable to acquire thedatabase locks it needs to do its job. If the statement is a COMMITor occurs outside of an explicit transaction, then you can retry thestatement. If the statement is not a COMMIT and occurs within anexplicit transaction then you should rollback the transaction beforecontinuing.
SQLITE_DONE means that the statement has finished executingsuccessfully. sqlite3_step() should not be called again on this virtualmachine without first calling sqlite3_reset() to reset the virtualmachine back to its initial state.
If the SQL statement being executed returns any data, then SQLITE_ROWis returned each time a new row of data is ready for processing by thecaller. The values may be accessed using the column access functions.sqlite3_step() is called again to retrieve the next row of data.
SQLITE_ERROR means that a run-time error (such as a constraintviolation) has occurred. sqlite3_step() should not be called again onthe VM. More information may be found by calling sqlite3_errmsg().With the legacy interface, a more specific error code (for example,SQLITE_INTERRUPT, SQLITE_SCHEMA, SQLITE_CORRUPT, and so forth)can be obtained by calling sqlite3_reset() on theprepared statement. In the "v2" interface,the more specific error code is returned directly by sqlite3_step().
SQLITE_MISUSE means that the this routine was called inappropriately.Perhaps it was called on a prepared statement that hasalready been finalized or on one that hadpreviously returned SQLITE_ERROR or SQLITE_DONE. Or it couldbe the case that the same database connection is being used by two ormore threads at the same moment in time.
For all versions of SQLite up to and including 3.6.23.1, a call tosqlite3_reset() was required after sqlite3_step() returned anythingother than SQLITE_ROW before any subsequent invocation ofsqlite3_step(). Failure to reset the prepared statement usingsqlite3_reset() would result in an SQLITE_MISUSE return fromsqlite3_step(). But after version 3.6.23.1, sqlite3_step() begancalling sqlite3_reset() automatically in this circumstance ratherthan returning SQLITE_MISUSE. This is not considered a compatibilitybreak because any application that ever receives an SQLITE_MISUSE erroris broken by definition. The SQLITE_OMIT_AUTORESET compile-time optioncan be used to restore the legacy behavior.
Goofy Interface Alert: In the legacy interface, the sqlite3_step()API always returns a generic error code, SQLITE_ERROR, following anyerror other than SQLITE_BUSY and SQLITE_MISUSE. You must callsqlite3_reset() or sqlite3_finalize() in order to find one of thespecific error codes that better describes the error.We admit that this is a goofy design. The problem has been fixedwith the "v2" interface. If you prepare all of your SQL statementsusing either sqlite3_prepare_v2() or sqlite3_prepare16_v2() insteadof the legacy sqlite3_prepare() and sqlite3_prepare16() interfaces,then the more specific error codes are returned directlyby sqlite3_step(). The use of the "v2" interface is recommended.
Determine If A Prepared Statement Has Been Resetint sqlite3_stmt_busy(sqlite3_stmt*);
The sqlite3_stmt_busy(S) interface returns true (non-zero) if theprepared statement S has been stepped at least once usingsqlite3_step(S) but has not run to completion and/or has notbeen reset using sqlite3_reset(S). The sqlite3_stmt_busy(S)interface returns false if S is a NULL pointer. If S is not aNULL pointer and is not a pointer to a valid prepared statementobject, then the behavior is undefined and probably undesirable.
This interface can be used in combination sqlite3_next_stmt()to locate all prepared statements associated with a databaseconnection that are in need of being reset. This can be used,for example, in diagnostic routines to search for preparedstatements that are holding a transaction open.
Determine If An SQL Statement Writes The Databaseint sqlite3_stmt_readonly(sqlite3_stmt *pStmt);
The sqlite3_stmt_readonly(X) interface returns true (non-zero) ifand only if the prepared statement X makes no direct changes tothe content of the database file.
Note that application-defined SQL functions orvirtual tables might change the database indirectly as a side effect.For example, if an application defines a function "eval()" thatcalls sqlite3_exec(), then the following SQL statement wouldchange the database file through side-effects:
SELECT eval('DELETE FROM t1') FROM t2;But because the SELECT statement does not change the database filedirectly, sqlite3_stmt_readonly() would still return true.
Transaction control statements such as BEGIN, COMMIT, ROLLBACK,SAVEPOINT, and RELEASE cause sqlite3_stmt_readonly() to return true,since the statements themselves do not actually modify the database butrather they control the timing of when other statements modify thedatabase. The ATTACH and DETACH statements also causesqlite3_stmt_readonly() to return true since, while those statementschange the configuration of a database connection, they do not makechanges to the content of the database files on disk.
Prepared Statement Statusint sqlite3_stmt_status(sqlite3_stmt*, int op,int resetFlg);
Each prepared statement maintains variousSQLITE_STMTSTATUS counters that measure the numberof times it has performed specific operations. These counters canbe used to monitor the performance characteristics of the preparedstatements. For example, if the number of table steps greatly exceedsthe number of table searches or result rows, that would tend to indicatethat the prepared statement is using a full table scan rather thanan index.
This interface is used to retrieve and reset counter values froma prepared statement. The first argument is the prepared statementobject to be interrogated. The second argumentis an integer code for a specific SQLITE_STMTSTATUS counterto be interrogated.The current value of the requested counter is returned.If the resetFlg is true, then the counter is reset to zero after thisinterface call returns.
See also: sqlite3_status() and sqlite3_db_status().
String Comparisonint sqlite3_strnicmp(const char *, const char *, int);
The sqlite3_strnicmp() API allows applications and extensions tocompare the contents of two buffers containing UTF-8 strings in acase-independent fashion, using the same definition of case independencethat SQLite uses internally when comparing identifiers.
Extract Metadata About A Column Of A Tableint sqlite3_table_column_metadata( sqlite3 *db, /* Connection handle */ const char *zDbName, /* Database name or NULL */ const char *zTableName, /* Table name */ const char *zColumnName, /* Column name */ char const **pzDataType, /* OUTPUT: Declared data type */ char const **pzCollSeq, /* OUTPUT: Collation sequence name */ int *pNotNull, /* OUTPUT: True if NOT NULL constraint exists */ int *pPrimaryKey, /* OUTPUT: True if column part of PK */ int *pAutoinc /* OUTPUT: True if column is auto-increment */);
This routine returns metadata about a specific column of a specificdatabase table accessible using the database connection handlepassed as the first function argument.
The column is identified by the second, third and fourth parameters tothis function. The second parameter is either the name of the database(i.e. "main", "temp", or an attached database) containing the specifiedtable or NULL. If it is NULL, then all attached databases are searchedfor the table using the same algorithm used by the database engine toresolve unqualified table references.
The third and fourth parameters to this function are the table and columnname of the desired column, respectively. Neither of these parametersmay be NULL.
Metadata is returned by writing to the memory locations passed as the 5thand subsequent parameters to this function. Any of these arguments may beNULL, in which case the corresponding element of metadata is omitted.
Parameter Output
Type Description 5th const char* Data type 6th const char* Name of default collation sequence 7th int True if column has a NOT NULL constraint 8th int True if column is part of the PRIMARY KEY 9th int True if column is AUTOINCREMENT
The memory pointed to by the character pointers returned for thedeclaration type and collation sequence is valid only until the nextcall to any SQLite API function.
If the specified table is actually a view, an error code is returned.
If the specified column is "rowid", "oid" or "_rowid_" and anINTEGER PRIMARY KEY column has been explicitly declared, then the outputparameters are set for the explicitly declared column. If there is noexplicitly declared INTEGER PRIMARY KEY column, then the outputparameters are set as follows:
data type: "INTEGER"collation sequence: "BINARY"not null: 0primary key: 1auto increment: 0
This function may load one or more schemas from database files. If anerror occurs during this process, or if the requested table or columncannot be found, an error code is returned and an error message leftin the database connection (to be retrieved using sqlite3_errmsg()).
This API is only available if the library was compiled with theSQLITE_ENABLE_COLUMN_METADATA C-preprocessor symbol defined.
Testing Interfaceint sqlite3_test_control(int op, ...);
The sqlite3_test_control() interface is used to read out internalstate of SQLite and to inject faults into SQLite for testingpurposes. The first parameter is an operation code that determinesthe number, meaning, and operation of all subsequent parameters.
This interface is not for use by applications. It exists solelyfor verifying the correct operation of the SQLite library. Dependingon how the SQLite library is compiled, this interface might not exist.
The details of the operation codes, their meanings, the parametersthey take, and what they do are all subject to change without notice.Unlike most of the SQLite API, this function is not guaranteed tooperate consistently from one release to the next.
Test To See If The Library Is Threadsafeint sqlite3_threadsafe(void);
The sqlite3_threadsafe() function returns zero if and only ifSQLite was compiled with mutexing code omitted due to theSQLITE_THREADSAFE compile-time option being set to 0.
SQLite can be compiled with or without mutexes. Whenthe SQLITE_THREADSAFE C preprocessor macro is 1 or 2, mutexesare enabled and SQLite is threadsafe. When theSQLITE_THREADSAFE macro is 0,the mutexes are omitted. Without the mutexes, it is not safeto use SQLite concurrently from more than one thread.
Enabling mutexes incurs a measurable performance penalty.So if speed is of utmost importance, it makes sense to disablethe mutexes. But for maximum safety, mutexes should be enabled.The default behavior is for mutexes to be enabled.
This interface can be used by an application to make sure that theversion of SQLite that it is linking against was compiled withthe desired setting of the SQLITE_THREADSAFE macro.
This interface only reports on the compile-time mutex settingof the SQLITE_THREADSAFE flag. If SQLite is compiled withSQLITE_THREADSAFE=1 or =2 then mutexes are enabled by default butcan be fully or partially disabled using a call to sqlite3_config()with the verbs SQLITE_CONFIG_SINGLETHREAD, SQLITE_CONFIG_MULTITHREAD,or SQLITE_CONFIG_MUTEX. The return value of thesqlite3_threadsafe() function shows only the compile-time setting ofthread safety, not any run-time changes to that setting made bysqlite3_config(). In other words, the return value from sqlite3_threadsafe()is unchanged by calls to sqlite3_config().
See the threading mode documentation for additional information.
Total Number Of Rows Modifiedint sqlite3_total_changes(sqlite3*);
This function returns the number of row changes caused by INSERT,UPDATE or DELETE statements since the database connection was opened.The count returned by sqlite3_total_changes() includes all changesfrom all trigger contexts and changes made byforeign key actions. However,the count does not include changes used to implement REPLACE constraints,do rollbacks or ABORT processing, or DROP TABLE processing. Thecount does not include rows of views that fire an INSTEAD OF trigger,though if the INSTEAD OF trigger makes changes of its own, those changesare counted.The sqlite3_total_changes() function counts the changes as soon asthe statement that makes them is completed (when the statement handleis passed to sqlite3_reset() or sqlite3_finalize()).
See also the sqlite3_changes() interface, thecount_changes pragma, and the total_changes() SQL function.
If a separate thread makes changes on the same database connectionwhile sqlite3_total_changes() is running then the valuereturned is unpredictable and not meaningful.
Unlock Notificationint sqlite3_unlock_notify( sqlite3 *pBlocked, /* Waiting connection */ void (*xNotify)(void **apArg, int nArg), /* Callback function to invoke */ void *pNotifyArg /* Argument to pass to xNotify */);
When running in shared-cache mode, a database operation may fail withan SQLITE_LOCKED error if the required locks on the shared-cache orindividual tables within the shared-cache cannot be obtained. SeeSQLite Shared-Cache Mode for a description of shared-cache locking.This API may be used to register a callback that SQLite will invokewhen the connection currently holding the required lock relinquishes it.This API is only available if the library was compiled with theSQLITE_ENABLE_UNLOCK_NOTIFY C-preprocessor symbol defined.
See Also: Using the SQLite Unlock Notification Feature.
Shared-cache locks are released when a database connection concludesits current transaction, either by committing it or rolling it back.
When a connection (known as the blocked connection) fails to obtain ashared-cache lock and SQLITE_LOCKED is returned to the caller, theidentity of the database connection (the blocking connection) thathas locked the required resource is stored internally. After anapplication receives an SQLITE_LOCKED error, it may call thesqlite3_unlock_notify() method with the blocked connection handle asthe first argument to register for a callback that will be invokedwhen the blocking connections current transaction is concluded. Thecallback is invoked from within the sqlite3_step or sqlite3_closecall that concludes the blocking connections transaction.
If sqlite3_unlock_notify() is called in a multi-threaded application,there is a chance that the blocking connection will have alreadyconcluded its transaction by the time sqlite3_unlock_notify() is invoked.If this happens, then the specified callback is invoked immediately,from within the call to sqlite3_unlock_notify().
If the blocked connection is attempting to obtain a write-lock on ashared-cache table, and more than one other connection currently holdsa read-lock on the same table, then SQLite arbitrarily selects one ofthe other connections to use as the blocking connection.
There may be at most one unlock-notify callback registered by ablocked connection. If sqlite3_unlock_notify() is called when theblocked connection already has a registered unlock-notify callback,then the new callback replaces the old. If sqlite3_unlock_notify() iscalled with a NULL pointer as its second argument, then any existingunlock-notify callback is canceled. The blocked connectionsunlock-notify callback may also be canceled by closing the blockedconnection using sqlite3_close().
The unlock-notify callback is not reentrant. If an application invokesany sqlite3_xxx API functions from within an unlock-notify callback, acrash or deadlock may be the result.
Unless deadlock is detected (see below), sqlite3_unlock_notify() alwaysreturns SQLITE_OK.
Callback Invocation Details
When an unlock-notify callback is registered, the application provides asingle void* pointer that is passed to the callback when it is invoked.However, the signature of the callback function allows SQLite to passit an array of void* context pointers. The first argument passed toan unlock-notify callback is a pointer to an array of void* pointers,and the second is the number of entries in the array.
When a blocking connections transaction is concluded, there may bemore than one blocked connection that has registered for an unlock-notifycallback. If two or more such blocked connections have specified thesame callback function, then instead of invoking the callback functionmultiple times, it is invoked once with the set of void* context pointersspecified by the blocked connections bundled together into an array.This gives the application an opportunity to prioritize any actionsrelated to the set of unblocked database connections.
Deadlock Detection
Assuming that after registering for an unlock-notify callback adatabase waits for the callback to be issued before taking any furtheraction (a reasonable assumption), then using this API may cause theapplication to deadlock. For example, if connection X is waiting forconnection Y's transaction to be concluded, and similarly connectionY is waiting on connection X's transaction, then neither connectionwill proceed and the system may remain deadlocked indefinitely.
To avoid this scenario, the sqlite3_unlock_notify() performs deadlockdetection. If a given call to sqlite3_unlock_notify() would put thesystem in a deadlocked state, then SQLITE_LOCKED is returned and nounlock-notify callback is registered. The system is said to be ina deadlocked state if connection A has registered for an unlock-notifycallback on the conclusion of connection B's transaction, and connectionB has itself registered for an unlock-notify callback when connectionA's transaction is concluded. Indirect deadlock is also detected, sothe system is also considered to be deadlocked if connection B hasregistered for an unlock-notify callback on the conclusion of connectionC's transaction, where connection C is waiting on connection A. Anynumber of levels of indirection are allowed.
The "DROP TABLE" Exception
When a call to sqlite3_step() returns SQLITE_LOCKED, it is almostalways appropriate to call sqlite3_unlock_notify(). There is however,one exception. When executing a "DROP TABLE" or "DROP INDEX" statement,SQLite checks if there are any currently executing SELECT statementsthat belong to the same connection. If there are, SQLITE_LOCKED isreturned. In this case there is no "blocking connection", so invokingsqlite3_unlock_notify() results in the unlock-notify callback beinginvoked immediately. If the application then re-attempts the "DROP TABLE"or "DROP INDEX" query, an infinite loop might be the result.
One way around this problem is to check the extended error code returnedby an sqlite3_step() call. If there is a blocking connection, then theextended error code is set to SQLITE_LOCKED_SHAREDCACHE. Otherwise, inthe special "DROP TABLE/INDEX" case, the extended error code is justSQLITE_LOCKED.
Data Change Notification Callbacksvoid *sqlite3_update_hook( sqlite3*, void(*)(void *,int ,char const *,char const *,sqlite3_int64), void*);
The sqlite3_update_hook() interface registers a callback functionwith the database connection identified by the first argumentto be invoked whenever a row is updated, inserted or deleted.Any callback set by a previous call to this functionfor the same database connection is overridden.
The second argument is a pointer to the function to invoke when arow is updated, inserted or deleted.The first argument to the callback is a copy of the third argumentto sqlite3_update_hook().The second callback argument is one of SQLITE_INSERT, SQLITE_DELETE,or SQLITE_UPDATE, depending on the operation that caused the callbackto be invoked.The third and fourth arguments to the callback contain pointers to thedatabase and table name containing the affected row.The final callback parameter is the rowid of the row.In the case of an update, this is the rowid after the update takes place.
The update hook is not invoked when internal system tables aremodified (i.e. sqlite_master and sqlite_sequence).
In the current implementation, the update hookis not invoked when duplication rows are deleted because of anON CONFLICT REPLACE clause. Nor is the update hookinvoked when rows are deleted using the truncate optimization.The exceptions defined in this paragraph might change in a futurerelease of SQLite.
The update hook implementation must not do anything that will modifythe database connection that invoked the update hook. Any actionsto modify the database connection must be deferred until after thecompletion of the sqlite3_step() call that triggered the update hook.Note that sqlite3_prepare_v2() and sqlite3_step() both modify theirdatabase connections for the meaning of "modify" in this paragraph.
The sqlite3_update_hook(D,C,P) functionreturns the P argument from the previous callon the same database connection D, or NULL forthe first call on D.
See also the sqlite3_commit_hook() and sqlite3_rollback_hook()interfaces.
User Data For Functionsvoid *sqlite3_user_data(sqlite3_context*);
The sqlite3_user_data() interface returns a copy ofthe pointer that was the pUserData parameter (the 5th parameter)of the sqlite3_create_function()and sqlite3_create_function16() routines that originallyregistered the application defined function.
This routine must be called from the same thread in whichthe application-defined function is running.
Virtual Table Interface Configurationint sqlite3_vtab_config(sqlite3*, int op, ...);
This function may be called by either the xConnect or xCreate methodof a virtual table implementation to configurevarious facets of the virtual table interface.
If this interface is invoked outside the context of an xConnect orxCreate virtual table method then the behavior is undefined.
At present, there is only one option that may be configured usingthis function. (See SQLITE_VTAB_CONSTRAINT_SUPPORT.) Further optionsmay be added in the future.
Determine The Virtual Table Conflict Policyint sqlite3_vtab_on_conflict(sqlite3 *);
This function may only be called from within a call to the xUpdate methodof a virtual table implementation for an INSERT or UPDATE operation. Thevalue returned is one of SQLITE_ROLLBACK, SQLITE_IGNORE, SQLITE_FAIL,SQLITE_ABORT, or SQLITE_REPLACE, according to the ON CONFLICT modeof the SQL statement that triggered the call to the xUpdate method of thevirtual table.
Configure an auto-checkpointint sqlite3_wal_autocheckpoint(sqlite3 *db, int N);
The sqlite3_wal_autocheckpoint(D,N) is a wrapper aroundsqlite3_wal_hook() that causes any database on database connection Dto automatically checkpointafter committing a transaction if there are N ormore frames in the write-ahead log file. Passing zero ora negative value as the nFrame parameter disables automaticcheckpoints entirely.
The callback registered by this function replaces any existing callbackregistered using sqlite3_wal_hook(). Likewise, registering a callbackusing sqlite3_wal_hook() disables the automatic checkpoint mechanismconfigured by this function.
The wal_autocheckpoint pragma can be used to invoke this interfacefrom SQL.
Every new database connection defaults to having the auto-checkpointenabled with a threshold of 1000 or SQLITE_DEFAULT_WAL_AUTOCHECKPOINTpages. The use of this interfaceis only necessary if the default setting is found to be suboptimalfor a particular application.
Checkpoint a databaseint sqlite3_wal_checkpoint(sqlite3 *db, const char *zDb);
The sqlite3_wal_checkpoint(D,X) interface causes database named Xon database connection D to be checkpointed. If X is NULL or anempty string, then a checkpoint is run on all databases ofconnection D. If the database connection D is not inwrite-ahead log mode then this interface is a harmless no-op.
The wal_checkpoint pragma can be used to invoke this interfacefrom SQL. The sqlite3_wal_autocheckpoint() interface and thewal_autocheckpoint pragma can be used to cause this interface to berun whenever the WAL reaches a certain size threshold.
See also: sqlite3_wal_checkpoint_v2()
Checkpoint a databaseint sqlite3_wal_checkpoint_v2( sqlite3 *db, /* Database handle */ const char *zDb, /* Name of attached database (or NULL) */ int eMode, /* SQLITE_CHECKPOINT_* value */ int *pnLog, /* OUT: Size of WAL log in frames */ int *pnCkpt /* OUT: Total number of frames checkpointed */);
Run a checkpoint operation on WAL database zDb attached to databasehandle db. The specific operation is determined by the value of theeMode parameter:
SQLITE_CHECKPOINT_PASSIVECheckpoint as many frames as possible without waiting for any databasereaders or writers to finish. Sync the db file if all frames in the logare checkpointed. This mode is the same as callingsqlite3_wal_checkpoint(). The busy-handler callback is never invoked.SQLITE_CHECKPOINT_FULLThis mode blocks (calls the busy-handler callback) until there is nodatabase writer and all readers are reading from the most recent databasesnapshot. It then checkpoints all frames in the log file and syncs thedatabase file. This call blocks database writers while it is running,but not database readers.SQLITE_CHECKPOINT_RESTARTThis mode works the same way as SQLITE_CHECKPOINT_FULL, except aftercheckpointing the log file it blocks (calls the busy-handler callback)until all readers are reading from the database file only. This ensuresthat the next client to write to the database file restarts the log filefrom the beginning. This call blocks database writers while it is running,but not database readers.If pnLog is not NULL, then *pnLog is set to the total number of frames inthe log file before returning. If pnCkpt is not NULL, then *pnCkpt is set tothe total number of checkpointed frames (including any that were alreadycheckpointed when this function is called). *pnLog and *pnCkpt may bepopulated even if sqlite3_wal_checkpoint_v2() returns other than SQLITE_OK.If no values are available because of an error, they are both set to -1before returning to communicate this to the caller.
All calls obtain an exclusive "checkpoint" lock on the database file. Ifany other process is running a checkpoint operation at the same time, thelock cannot be obtained and SQLITE_BUSY is returned. Even if there is abusy-handler configured, it will not be invoked in this case.
The SQLITE_CHECKPOINT_FULL and RESTART modes also obtain the exclusive"writer" lock on the database file. If the writer lock cannot be obtainedimmediately, and a busy-handler is configured, it is invoked and the writerlock retried until either the busy-handler returns 0 or the lock issuccessfully obtained. The busy-handler is also invoked while waiting fordatabase readers as described above. If the busy-handler returns 0 beforethe writer lock is obtained or while waiting for database readers, thecheckpoint operation proceeds from that point in the same way asSQLITE_CHECKPOINT_PASSIVE - checkpointing as many frames as possiblewithout blocking any further. SQLITE_BUSY is returned in this case.
If parameter zDb is NULL or points to a zero length string, then thespecified operation is attempted on all WAL databases. In this case thevalues written to output parameters *pnLog and *pnCkpt are undefined. Ifan SQLITE_BUSY error is encountered when processing one or more of theattached WAL databases, the operation is still attempted on any remainingattached databases and SQLITE_BUSY is returned to the caller. If any othererror occurs while processing an attached database, processing is abandonedand the error code returned to the caller immediately. If no error(SQLITE_BUSY or otherwise) is encountered while processing the attacheddatabases, SQLITE_OK is returned.
If database zDb is the name of an attached database that is not in WALmode, SQLITE_OK is returned and both *pnLog and *pnCkpt set to -1. IfzDb is not NULL (or a zero length string) and is not the name of anyattached database, SQLITE_ERROR is returned to the caller.
Write-Ahead Log Commit Hookvoid *sqlite3_wal_hook( sqlite3*, int(*)(void *,sqlite3*,const char*,int), void*);
The sqlite3_wal_hook() function is used to register a callback thatwill be invoked each time a database connection commits data to awrite-ahead log (i.e. whenever a transaction is committed injournal_mode=WAL mode).
The callback is invoked by SQLite after the commit has taken place andthe associated write-lock on the database released, so the implementationmay read, write or checkpoint the database as required.
The first parameter passed to the callback function when it is invokedis a copy of the third parameter passed to sqlite3_wal_hook() whenregistering the callback. The second is a copy of the database handle.The third parameter is the name of the database that was written to -either "main" or the name of an ATTACH-ed database. The fourth parameteris the number of pages currently in the write-ahead log file,including those that were just committed.
The callback function should normally return SQLITE_OK. If an errorcode is returned, that error will propagate back up through theSQLite code base to cause the statement that provoked the callbackto report an error, though the commit will have still occurred. If thecallback returns SQLITE_ROW or SQLITE_DONE, or if it returns a valuethat does not correspond to any valid SQLite error code, the resultsare undefined.
A single database handle may have at most a single write-ahead log callbackregistered at one time. Calling sqlite3_wal_hook() replaces anypreviously registered write-ahead log callback. Note that thesqlite3_wal_autocheckpoint() interface and thewal_autocheckpoint pragma both invoke sqlite3_wal_hook() and willthose overwrite any prior sqlite3_wal_hook() settings.
Result Codes#define SQLITE_OK 0 /* Successful result *//* beginning-of-error-codes */#define SQLITE_ERROR 1 /* SQL error or missing database */#define SQLITE_INTERNAL 2 /* Internal logic error in SQLite */#define SQLITE_PERM 3 /* Access permission denied */#define SQLITE_ABORT 4 /* Callback routine requested an abort */#define SQLITE_BUSY 5 /* The database file is locked */#define SQLITE_LOCKED 6 /* A table in the database is locked */#define SQLITE_NOMEM 7 /* A malloc() failed */#define SQLITE_READONLY 8 /* Attempt to write a readonly database */#define SQLITE_INTERRUPT 9 /* Operation terminated by sqlite3_interrupt()*/#define SQLITE_IOERR 10 /* Some kind of disk I/O error occurred */#define SQLITE_CORRUPT 11 /* The database disk image is malformed */#define SQLITE_NOTFOUND 12 /* Unknown opcode in sqlite3_file_control() */#define SQLITE_FULL 13 /* Insertion failed because database is full */#define SQLITE_CANTOPEN 14 /* Unable to open the database file */#define SQLITE_PROTOCOL 15 /* Database lock protocol error */#define SQLITE_EMPTY 16 /* Database is empty */#define SQLITE_SCHEMA 17 /* The database schema changed */#define SQLITE_TOOBIG 18 /* String or BLOB exceeds size limit */#define SQLITE_CONSTRAINT 19 /* Abort due to constraint violation */#define SQLITE_MISMATCH 20 /* Data type mismatch */#define SQLITE_MISUSE 21 /* Library used incorrectly */#define SQLITE_NOLFS 22 /* Uses OS features not supported on host */#define SQLITE_AUTH 23 /* Authorization denied */#define SQLITE_FORMAT 24 /* Auxiliary database format error */#define SQLITE_RANGE 25 /* 2nd parameter to sqlite3_bind out of range */#define SQLITE_NOTADB 26 /* File opened that is not a database file */#define SQLITE_ROW 100 /* sqlite3_step() has another row ready */#define SQLITE_DONE 101 /* sqlite3_step() has finished executing *//* end-of-error-codes */
Many SQLite functions return an integer result code from the set shownhere in order to indicate success or failure.
New error codes may be added in future versions of SQLite.
See also: extended result codes,sqlite3_vtab_on_conflict() result codes.
Flags for the xAccess VFS method#define SQLITE_ACCESS_EXISTS 0#define SQLITE_ACCESS_READWRITE 1 /* Used by PRAGMA temp_store_directory */#define SQLITE_ACCESS_READ 2 /* Unused */
These integer constants can be used as the third parameter tothe xAccess method of an sqlite3_vfs object. They determinewhat kind of permissions the xAccess method is looking for.With SQLITE_ACCESS_EXISTS, the xAccess methodsimply checks whether the file exists.With SQLITE_ACCESS_READWRITE, the xAccess methodchecks whether the named directory is both readable and writable(in other words, if files can be added, removed, and renamed withinthe directory).The SQLITE_ACCESS_READWRITE constant is currently used only by thetemp_store_directory pragma, though this could change in a futurerelease of SQLite.With SQLITE_ACCESS_READ, the xAccess methodchecks whether the file is readable. The SQLITE_ACCESS_READ constant iscurrently unused, though it might be used in a future release ofSQLite.
Authorizer Action Codes/******************************************* 3rd ************ 4th ***********/#define SQLITE_CREATE_INDEX 1 /* Index Name Table Name */#define SQLITE_CREATE_TABLE 2 /* Table Name NULL */#define SQLITE_CREATE_TEMP_INDEX 3 /* Index Name Table Name */#define SQLITE_CREATE_TEMP_TABLE 4 /* Table Name NULL */#define SQLITE_CREATE_TEMP_TRIGGER 5 /* Trigger Name Table Name */#define SQLITE_CREATE_TEMP_VIEW 6 /* View Name NULL */#define SQLITE_CREATE_TRIGGER 7 /* Trigger Name Table Name */#define SQLITE_CREATE_VIEW 8 /* View Name NULL */#define SQLITE_DELETE 9 /* Table Name NULL */#define SQLITE_DROP_INDEX 10 /* Index Name Table Name */#define SQLITE_DROP_TABLE 11 /* Table Name NULL */#define SQLITE_DROP_TEMP_INDEX 12 /* Index Name Table Name */#define SQLITE_DROP_TEMP_TABLE 13 /* Table Name NULL */#define SQLITE_DROP_TEMP_TRIGGER 14 /* Trigger Name Table Name */#define SQLITE_DROP_TEMP_VIEW 15 /* View Name NULL */#define SQLITE_DROP_TRIGGER 16 /* Trigger Name Table Name */#define SQLITE_DROP_VIEW 17 /* View Name NULL */#define SQLITE_INSERT 18 /* Table Name NULL */#define SQLITE_PRAGMA 19 /* Pragma Name 1st arg or NULL */#define SQLITE_READ 20 /* Table Name Column Name */#define SQLITE_SELECT 21 /* NULL NULL */#define SQLITE_TRANSACTION 22 /* Operation NULL */#define SQLITE_UPDATE 23 /* Table Name Column Name */#define SQLITE_ATTACH 24 /* Filename NULL */#define SQLITE_DETACH 25 /* Database Name NULL */#define SQLITE_ALTER_TABLE 26 /* Database Name Table Name */#define SQLITE_REINDEX 27 /* Index Name NULL */#define SQLITE_ANALYZE 28 /* Table Name NULL */#define SQLITE_CREATE_VTABLE 29 /* Table Name Module Name */#define SQLITE_DROP_VTABLE 30 /* Table Name Module Name */#define SQLITE_FUNCTION 31 /* NULL Function Name */#define SQLITE_SAVEPOINT 32 /* Operation Savepoint Name */#define SQLITE_COPY 0 /* No longer used */
The sqlite3_set_authorizer() interface registers a callback functionthat is invoked to authorize certain SQL statement actions. Thesecond parameter to the callback is an integer code that specifieswhat action is being authorized. These are the integer action codes thatthe authorizer callback may be passed.
These action code values signify what kind of operation is to beauthorized. The 3rd and 4th parameters to the authorizationcallback function will be parameters or NULL depending on which of thesecodes is used as the second parameter. The 5th parameter to theauthorizer callback is the name of the database ("main", "temp",etc.) if applicable. The 6th parameter to the authorizer callbackis the name of the inner-most trigger or view that is responsible forthe access attempt or NULL if this access attempt is directly fromtop-level SQL code.
Text Encodings#define SQLITE_UTF8 1#define SQLITE_UTF16LE 2#define SQLITE_UTF16BE 3#define SQLITE_UTF16 4 /* Use native byte order */#define SQLITE_ANY 5 /* sqlite3_create_function only */#define SQLITE_UTF16_ALIGNED 8 /* sqlite3_create_collation only */
These constant define integer codes that represent the varioustext encodings supported by SQLite.
Fundamental Datatypes#define SQLITE_INTEGER 1#define SQLITE_FLOAT 2#define SQLITE_BLOB 4#define SQLITE_NULL 5#ifdef SQLITE_TEXT# undef SQLITE_TEXT#else# define SQLITE_TEXT 3#endif#define SQLITE3_TEXT 3
Every value in SQLite has one of five fundamental datatypes:
64-bit signed integer 64-bit IEEE floating point number string BLOB NULLThese constants are codes for each of those types.
Note that the SQLITE_TEXT constant was also used in SQLite version 2for a completely different meaning. Software that links against bothSQLite version 2 and SQLite version 3 should use SQLITE3_TEXT, notSQLITE_TEXT.
Extended Result Codes#define SQLITE_IOERR_READ (SQLITE_IOERR | (1<<8))#define SQLITE_IOERR_SHORT_READ (SQLITE_IOERR | (2<<8))#define SQLITE_IOERR_WRITE (SQLITE_IOERR | (3<<8))#define SQLITE_IOERR_FSYNC (SQLITE_IOERR | (4<<8))#define SQLITE_IOERR_DIR_FSYNC (SQLITE_IOERR | (5<<8))#define SQLITE_IOERR_TRUNCATE (SQLITE_IOERR | (6<<8))#define SQLITE_IOERR_FSTAT (SQLITE_IOERR | (7<<8))#define SQLITE_IOERR_UNLOCK (SQLITE_IOERR | (8<<8))#define SQLITE_IOERR_RDLOCK (SQLITE_IOERR | (9<<8))#define SQLITE_IOERR_DELETE (SQLITE_IOERR | (10<<8))#define SQLITE_IOERR_BLOCKED (SQLITE_IOERR | (11<<8))#define SQLITE_IOERR_NOMEM (SQLITE_IOERR | (12<<8))#define SQLITE_IOERR_ACCESS (SQLITE_IOERR | (13<<8))#define SQLITE_IOERR_CHECKRESERVEDLOCK (SQLITE_IOERR | (14<<8))#define SQLITE_IOERR_LOCK (SQLITE_IOERR | (15<<8))#define SQLITE_IOERR_CLOSE (SQLITE_IOERR | (16<<8))#define SQLITE_IOERR_DIR_CLOSE (SQLITE_IOERR | (17<<8))#define SQLITE_IOERR_SHMOPEN (SQLITE_IOERR | (18<<8))#define SQLITE_IOERR_SHMSIZE (SQLITE_IOERR | (19<<8))#define SQLITE_IOERR_SHMLOCK (SQLITE_IOERR | (20<<8))#define SQLITE_IOERR_SHMMAP (SQLITE_IOERR | (21<<8))#define SQLITE_IOERR_SEEK (SQLITE_IOERR | (22<<8))#define SQLITE_LOCKED_SHAREDCACHE (SQLITE_LOCKED | (1<<8))#define SQLITE_BUSY_RECOVERY (SQLITE_BUSY | (1<<8))#define SQLITE_CANTOPEN_NOTEMPDIR (SQLITE_CANTOPEN | (1<<8))#define SQLITE_CORRUPT_VTAB (SQLITE_CORRUPT | (1<<8))#define SQLITE_READONLY_RECOVERY (SQLITE_READONLY | (1<<8))#define SQLITE_READONLY_CANTLOCK (SQLITE_READONLY | (2<<8))
In its default configuration, SQLite API routines return one of 26 integerresult codes. However, experience has shown that many ofthese result codes are too coarse-grained. They do not provide asmuch information about problems as programmers might like. In an effort toaddress this, newer versions of SQLite (version 3.3.8 and later) includesupport for additional result codes that provide more detailed informationabout errors. The extended result codes are enabled or disabledon a per database connection basis using thesqlite3_extended_result_codes() API.
Some of the available extended result codes are listed here.One may expect the number of extended result codes will be expandover time. Software that uses extended result codes should expectto see new result codes in future releases of SQLite.
The SQLITE_OK result code will never be extended. It will alwaysbe exactly zero.
Checkpoint operation parameters#define SQLITE_CHECKPOINT_PASSIVE 0#define SQLITE_CHECKPOINT_FULL 1#define SQLITE_CHECKPOINT_RESTART 2
These constants can be used as the 3rd parameter tosqlite3_wal_checkpoint_v2(). See the sqlite3_wal_checkpoint_v2()documentation for additional information about the meaning and use ofeach of these values.
Configuration Options#define SQLITE_CONFIG_SINGLETHREAD 1 /* nil */#define SQLITE_CONFIG_MULTITHREAD 2 /* nil */#define SQLITE_CONFIG_SERIALIZED 3 /* nil */#define SQLITE_CONFIG_MALLOC 4 /* sqlite3_mem_methods* */#define SQLITE_CONFIG_GETMALLOC 5 /* sqlite3_mem_methods* */#define SQLITE_CONFIG_SCRATCH 6 /* void*, int sz, int N */#define SQLITE_CONFIG_PAGECACHE 7 /* void*, int sz, int N */#define SQLITE_CONFIG_HEAP 8 /* void*, int nByte, int min */#define SQLITE_CONFIG_MEMSTATUS 9 /* boolean */#define SQLITE_CONFIG_MUTEX 10 /* sqlite3_mutex_methods* */#define SQLITE_CONFIG_GETMUTEX 11 /* sqlite3_mutex_methods* *//* previously SQLITE_CONFIG_CHUNKALLOC 12 which is now unused. */ #define SQLITE_CONFIG_LOOKASIDE 13 /* int int */#define SQLITE_CONFIG_PCACHE 14 /* no-op */#define SQLITE_CONFIG_GETPCACHE 15 /* no-op */#define SQLITE_CONFIG_LOG 16 /* xFunc, void* */#define SQLITE_CONFIG_URI 17 /* int */#define SQLITE_CONFIG_PCACHE2 18 /* sqlite3_pcache_methods2* */#define SQLITE_CONFIG_GETPCACHE2 19 /* sqlite3_pcache_methods2* */
These constants are the available integer configuration options thatcan be passed as the first argument to the sqlite3_config() interface.
New configuration options may be added in future releases of SQLite.Existing configuration options might be discontinued. Applicationsshould check the return code from sqlite3_config() to make sure thatthe call worked. The sqlite3_config() interface will return anon-zero error code if a discontinued or unsupported configuration optionis invoked.
SQLITE_CONFIG_SINGLETHREADThere are no arguments to this option. This option sets thethreading mode to Single-thread. In other words, it disablesall mutexing and puts SQLite into a mode where it can only be usedby a single thread. If SQLite is compiled withthe SQLITE_THREADSAFE=0 compile-time option thenit is not possible to change the threading mode from its defaultvalue of Single-thread and so sqlite3_config() will returnSQLITE_ERROR if called with the SQLITE_CONFIG_SINGLETHREADconfiguration option.SQLITE_CONFIG_MULTITHREADThere are no arguments to this option. This option sets thethreading mode to Multi-thread. In other words, it disablesmutexing on database connection and prepared statement objects.The application is responsible for serializing access todatabase connections and prepared statements. But other mutexesare enabled so that SQLite will be safe to use in a multi-threadedenvironment as long as no two threads attempt to use the samedatabase connection at the same time. If SQLite is compiled withthe SQLITE_THREADSAFE=0 compile-time option thenit is not possible to set the Multi-thread threading mode andsqlite3_config() will return SQLITE_ERROR if called with theSQLITE_CONFIG_MULTITHREAD configuration option.
SQLITE_CONFIG_SERIALIZEDThere are no arguments to this option. This option sets thethreading mode to Serialized. In other words, this option enablesall mutexes including the recursivemutexes on database connection and prepared statement objects.In this mode (which is the default when SQLite is compiled withSQLITE_THREADSAFE=1) the SQLite library will itself serialize accessto database connections and prepared statements so that theapplication is free to use the same database connection or thesame prepared statement in different threads at the same time.If SQLite is compiled withthe SQLITE_THREADSAFE=0 compile-time option thenit is not possible to set the Serialized threading mode andsqlite3_config() will return SQLITE_ERROR if called with theSQLITE_CONFIG_SERIALIZED configuration option.
SQLITE_CONFIG_MALLOC This option takes a single argument which is a pointer to aninstance of the sqlite3_mem_methods structure. The argument specifiesalternative low-level memory allocation routines to be used in place ofthe memory allocation routines built into SQLite. SQLite makesits own private copy of the content of the sqlite3_mem_methods structurebefore the sqlite3_config() call returns.
SQLITE_CONFIG_GETMALLOC This option takes a single argument which is a pointer to aninstance of the sqlite3_mem_methods structure. The sqlite3_mem_methodsstructure is filled with the currently defined memory allocation routines.This option can be used to overload the default memory allocationroutines with a wrapper that simulations memory allocation failure ortracks memory usage, for example.
SQLITE_CONFIG_MEMSTATUS This option takes single argument of type int, interpreted as aboolean, which enables or disables the collection of memory allocationstatistics. When memory allocation statistics are disabled, thefollowing SQLite interfaces become non-operational: sqlite3_memory_used() sqlite3_memory_highwater() sqlite3_soft_heap_limit64() sqlite3_status()Memory allocation statistics are enabled by default unless SQLite iscompiled with SQLITE_DEFAULT_MEMSTATUS=0 in which case memoryallocation statistics are disabled by default.
SQLITE_CONFIG_SCRATCH This option specifies a static memory buffer that SQLite can use forscratch memory. There are three arguments: A pointer an 8-bytealigned memory buffer from which the scratch allocations will bedrawn, the size of each scratch allocation (sz),and the maximum number of scratch allocations (N). The szargument must be a multiple of 16.The first argument must be a pointer to an 8-byte aligned bufferof at least sz*N bytes of memory.SQLite will use no more than two scratch buffers per thread. SoN should be set to twice the expected maximum number of threads.SQLite will never require a scratch buffer that is more than 6times the database page size. If SQLite needs needs additionalscratch memory beyond what is provided by this configuration option, thensqlite3_malloc() will be used to obtain the memory needed.
SQLITE_CONFIG_PAGECACHE This option specifies a static memory buffer that SQLite can use forthe database page cache with the default page cache implementation.This configuration should not be used if an application-define pagecache implementation is loaded using the SQLITE_CONFIG_PCACHE2 option.There are three arguments to this option: A pointer to 8-byte alignedmemory, the size of each page buffer (sz), and the number of pages (N).The sz argument should be the size of the largest database page(a power of two between 512 and 32768) plus a little extra for eachpage header. The page header size is 20 to 40 bytes depending onthe host architecture. It is harmless, apart from the wasted memory,to make sz a little too large. The firstargument should point to an allocation of at least sz*N bytes of memory.SQLite will use the memory provided by the first argument to satisfy itsmemory needs for the first N pages that it adds to cache. If additionalpage cache memory is needed beyond what is provided by this option, thenSQLite goes to sqlite3_malloc() for the additional storage space.The pointer in the first argument mustbe aligned to an 8-byte boundary or subsequent behavior of SQLitewill be undefined.
SQLITE_CONFIG_HEAP This option specifies a static memory buffer that SQLite will usefor all of its dynamic memory allocation needs beyond those providedfor by SQLITE_CONFIG_SCRATCH and SQLITE_CONFIG_PAGECACHE.There are three arguments: An 8-byte aligned pointer to the memory,the number of bytes in the memory buffer, and the minimum allocation size.If the first pointer (the memory pointer) is NULL, then SQLite revertsto using its default memory allocator (the system malloc() implementation),undoing any prior invocation of SQLITE_CONFIG_MALLOC. If thememory pointer is not NULL and either SQLITE_ENABLE_MEMSYS3 orSQLITE_ENABLE_MEMSYS5 are defined, then the alternative memoryallocator is engaged to handle all of SQLites memory allocation needs.The first pointer (the memory pointer) must be aligned to an 8-byteboundary or subsequent behavior of SQLite will be undefined.The minimum allocation size is capped at 2**12. Reasonable valuesfor the minimum allocation size are 2**5 through 2**8.
SQLITE_CONFIG_MUTEX This option takes a single argument which is a pointer to aninstance of the sqlite3_mutex_methods structure. The argument specifiesalternative low-level mutex routines to be used in placethe mutex routines built into SQLite. SQLite makes a copy of thecontent of the sqlite3_mutex_methods structure before the call tosqlite3_config() returns. If SQLite is compiled withthe SQLITE_THREADSAFE=0 compile-time option thenthe entire mutexing subsystem is omitted from the build and hence calls tosqlite3_config() with the SQLITE_CONFIG_MUTEX configuration option willreturn SQLITE_ERROR.
SQLITE_CONFIG_GETMUTEX This option takes a single argument which is a pointer to aninstance of the sqlite3_mutex_methods structure. Thesqlite3_mutex_methodsstructure is filled with the currently defined mutex routines.This option can be used to overload the default mutex allocationroutines with a wrapper used to track mutex usage for performanceprofiling or testing, for example. If SQLite is compiled withthe SQLITE_THREADSAFE=0 compile-time option thenthe entire mutexing subsystem is omitted from the build and hence calls tosqlite3_config() with the SQLITE_CONFIG_GETMUTEX configuration option willreturn SQLITE_ERROR.
SQLITE_CONFIG_LOOKASIDE This option takes two arguments that determine the defaultmemory allocation for the lookaside memory allocator on eachdatabase connection. The first argument is thesize of each lookaside buffer slot and the second is the number ofslots allocated to each database connection. This option sets thedefault lookaside size. The SQLITE_DBCONFIG_LOOKASIDEverb to sqlite3_db_config() can be used to change the lookasideconfiguration on individual connections.
SQLITE_CONFIG_PCACHE2 This option takes a single argument which is a pointer toan sqlite3_pcache_methods2 object. This object specifies the interfaceto a custom page cache implementation. SQLite makes a copy of theobject and uses it for page cache memory allocations.
SQLITE_CONFIG_GETPCACHE2 This option takes a single argument which is a pointer to ansqlite3_pcache_methods2 object. SQLite copies of the currentpage cache implementation into that object.
SQLITE_CONFIG_LOG The SQLITE_CONFIG_LOG option takes two arguments: a pointer to afunction with a call signature of void(*)(void*,int,const char*),and a pointer to void. If the function pointer is not NULL, it isinvoked by sqlite3_log() to process each logging event. If thefunction pointer is NULL, the sqlite3_log() interface becomes a no-op.The void pointer that is the second argument to SQLITE_CONFIG_LOG ispassed through as the first parameter to the application-defined loggerfunction whenever that function is invoked. The second parameter tothe logger function is a copy of the first parameter to the correspondingsqlite3_log() call and is intended to be a result code or anextended result code. The third parameter passed to the logger islog message after formatting via sqlite3_snprintf().The SQLite logging interface is not reentrant; the logger functionsupplied by the application must not invoke any SQLite interface.In a multi-threaded application, the application-defined loggerfunction must be threadsafe.
SQLITE_CONFIG_URI This option takes a single argument of type int. If non-zero, thenURI handling is globally enabled. If the parameter is zero, then URI handlingis globally disabled. If URI handling is globally enabled, all filenamespassed to sqlite3_open(), sqlite3_open_v2(), sqlite3_open16() orspecified as part of ATTACH commands are interpreted as URIs, regardlessof whether or not the SQLITE_OPEN_URI flag is set when the databaseconnection is opened. If it is globally disabled, filenames areonly interpreted as URIs if the SQLITE_OPEN_URI flag is set when thedatabase connection is opened. By default, URI handling is globallydisabled. The default value may be changed by compiling with theSQLITE_USE_URI symbol defined.
SQLITE_CONFIG_PCACHE and SQLITE_CONFNIG_GETPCACHE These options are obsolete and should not be used by new code.They are retained for backwards compatibility but are now no-ops.Database Connection Configuration Options
#define SQLITE_DBCONFIG_LOOKASIDE 1001 /* void* int int */#define SQLITE_DBCONFIG_ENABLE_FKEY 1002 /* int int* */#define SQLITE_DBCONFIG_ENABLE_TRIGGER 1003 /* int int* */
These constants are the available integer configuration options thatcan be passed as the second argument to the sqlite3_db_config() interface.
New configuration options may be added in future releases of SQLite.Existing configuration options might be discontinued. Applicationsshould check the return code from sqlite3_db_config() to make sure thatthe call worked. The sqlite3_db_config() interface will return anon-zero error code if a discontinued or unsupported configuration optionis invoked.
SQLITE_DBCONFIG_LOOKASIDE This option takes three additional arguments that determine thelookaside memory allocator configuration for the database connection.The first argument (the third parameter to sqlite3_db_config() is apointer to a memory buffer to use for lookaside memory.The first argument after the SQLITE_DBCONFIG_LOOKASIDE verbmay be NULL in which case SQLite will allocate thelookaside buffer itself using sqlite3_malloc(). The second argument is thesize of each lookaside buffer slot. The third argument is the number ofslots. The size of the buffer in the first argument must be greater thanor equal to the product of the second and third arguments. The buffermust be aligned to an 8-byte boundary. If the second argument toSQLITE_DBCONFIG_LOOKASIDE is not a multiple of 8, it is internallyrounded down to the next smaller multiple of 8. The lookaside memoryconfiguration for a database connection can only be changed when thatconnection is not currently using lookaside memory, or in other wordswhen the "current value" returned bysqlite3_db_status(D,SQLITE_CONFIG_LOOKASIDE,...) is zero.Any attempt to change the lookaside memory configuration when lookasidememory is in use leaves the configuration unchanged and returnsSQLITE_BUSY.SQLITE_DBCONFIG_ENABLE_FKEY This option is used to enable or disable the enforcement offoreign key constraints. There should be two additional arguments.The first argument is an integer which is 0 to disable FK enforcement,positive to enable FK enforcement or negative to leave FK enforcementunchanged. The second parameter is a pointer to an integer into whichis written 0 or 1 to indicate whether FK enforcement is off or onfollowing this call. The second parameter may be a NULL pointer, inwhich case the FK enforcement setting is not reported back. SQLITE_DBCONFIG_ENABLE_TRIGGER This option is used to enable or disable triggers.There should be two additional arguments.The first argument is an integer which is 0 to disable triggers,positive to enable triggers or negative to leave the setting unchanged.The second parameter is a pointer to an integer into whichis written 0 or 1 to indicate whether triggers are disabled or enabledfollowing this call. The second parameter may be a NULL pointer, inwhich case the trigger setting is not reported back. Authorizer Return Codes#define SQLITE_DENY 1 /* Abort the SQL statement with an error */#define SQLITE_IGNORE 2 /* Don't allow access, but don't generate an error */
The authorizer callback function mustreturn either SQLITE_OK or one of these two constants in orderto signal SQLite whether or not the action is permitted. See theauthorizer documentation for additionalinformation.
Note that SQLITE_IGNORE is also used as a return codefrom the sqlite3_vtab_on_conflict() interface.
Conflict resolution modes#define SQLITE_ROLLBACK 1/* #define SQLITE_IGNORE 2 // Also used by sqlite3_authorizer() callback */#define SQLITE_FAIL 3/* #define SQLITE_ABORT 4 // Also an error code */#define SQLITE_REPLACE 5
These constants are returned by sqlite3_vtab_on_conflict() toinform a virtual table implementation what the ON CONFLICT modeis for the SQL statement being evaluated.
Note that the SQLITE_IGNORE constant is also used as a potentialreturn value from the sqlite3_set_authorizer() callback and thatSQLITE_ABORT is also a result code.
Standard File Control Opcodes#define SQLITE_FCNTL_LOCKSTATE 1#define SQLITE_GET_LOCKPROXYFILE 2#define SQLITE_SET_LOCKPROXYFILE 3#define SQLITE_LAST_ERRNO 4#define SQLITE_FCNTL_SIZE_HINT 5#define SQLITE_FCNTL_CHUNK_SIZE 6#define SQLITE_FCNTL_FILE_POINTER 7#define SQLITE_FCNTL_SYNC_OMITTED 8#define SQLITE_FCNTL_WIN32_AV_RETRY 9#define SQLITE_FCNTL_PERSIST_WAL 10#define SQLITE_FCNTL_OVERWRITE 11#define SQLITE_FCNTL_VFSNAME 12#define SQLITE_FCNTL_POWERSAFE_OVERWRITE 13
These integer constants are opcodes for the xFileControl methodof the sqlite3_io_methods object and for the sqlite3_file_control()interface.
The SQLITE_FCNTL_LOCKSTATE opcode is used for debugging. Thisopcode causes the xFileControl method to write the current state ofthe lock (one of SQLITE_LOCK_NONE, SQLITE_LOCK_SHARED,SQLITE_LOCK_RESERVED, SQLITE_LOCK_PENDING, or SQLITE_LOCK_EXCLUSIVE)into an integer that the pArg argument points to. This capabilityis used during testing and only needs to be supported when SQLITE_TESTis defined.
The SQLITE_FCNTL_SIZE_HINT opcode is used by SQLite to give the VFSlayer a hint of how large the database file will grow to be during thecurrent transaction. This hint is not guaranteed to be accurate but itis often close. The underlying VFS might choose to preallocate databasefile space based on this hint in order to help writes to the databasefile run faster.
The SQLITE_FCNTL_CHUNK_SIZE opcode is used to request that the VFSextends and truncates the database file in chunks of a size specifiedby the user. The fourth argument to sqlite3_file_control() shouldpoint to an integer (type int) containing the new chunk-size to usefor the nominated database. Allocating database file space in largechunks (say 1MB at a time), may reduce file-system fragmentation andimprove performance on some systems.
The SQLITE_FCNTL_FILE_POINTER opcode is used to obtain a pointerto the sqlite3_file object associated with a particular databaseconnection. See the sqlite3_file_control() documentation foradditional information.
The SQLITE_FCNTL_SYNC_OMITTED opcode is generated internally bySQLite and sent to all VFSes in place of a call to the xSync methodwhen the database connection has PRAGMA synchronous set to OFF.Some specialized VFSes need this signal in order to operate correctlywhen PRAGMA synchronous=OFF is set, but mostVFSes do not need this signal and should silently ignore this opcode.Applications should not call sqlite3_file_control() with thisopcode as doing so may disrupt the operation of the specialized VFSesthat do require it.
The SQLITE_FCNTL_WIN32_AV_RETRY opcode is used to configure automaticretry counts and intervals for certain disk I/O operations for thewindows VFS in order to provide robustness in the presence ofanti-virus programs. By default, the windows VFS will retry file read,file write, and file delete operations up to 10 times, with a delayof 25 milliseconds before the first retry and with the delay increasingby an additional 25 milliseconds with each subsequent retry. Thisopcode allows these two values (10 retries and 25 milliseconds of delay)to be adjusted. The values are changed for all database connectionswithin the same process. The argument is a pointer to an array of twointegers where the first integer i the new retry count and the secondinteger is the delay. If either integer is negative, then the settingis not changed but instead the prior value of that setting is writteninto the array entry, allowing the current retry settings to beinterrogated. The zDbName parameter is ignored.
The SQLITE_FCNTL_PERSIST_WAL opcode is used to set or query thepersistent Write AHead Log setting. By default, the auxiliarywrite ahead log and shared memory files used for transaction controlare automatically deleted when the latest connection to the databasecloses. Setting persistent WAL mode causes those files to persist afterclose. Persisting the files is useful when other processes that do nothave write permission on the directory containing the database file wantto read the database file, as the WAL and shared memory files must existin order for the database to be readable. The fourth parameter tosqlite3_file_control() for this opcode should be a pointer to an integer.That integer is 0 to disable persistent WAL mode or 1 to enable persistentWAL mode. If the integer is -1, then it is overwritten with the currentWAL persistence setting.
The SQLITE_FCNTL_POWERSAFE_OVERWRITE opcode is used to set or query thepersistent "powersafe-overwrite" or "PSOW" setting. The PSOW settingdetermines the SQLITE_IOCAP_POWERSAFE_OVERWRITE bit of thexDeviceCharacteristics methods. The fourth parameter tosqlite3_file_control() for this opcode should be a pointer to an integer.That integer is 0 to disable zero-damage mode or 1 to enable zero-damagemode. If the integer is -1, then it is overwritten with the currentzero-damage mode setting.
The SQLITE_FCNTL_OVERWRITE opcode is invoked by SQLite after openinga write transaction to indicate that, unless it is rolled back for somereason, the entire database file will be overwritten by the currenttransaction. This is used by VACUUM operations.
The SQLITE_FCNTL_VFSNAME opcode can be used to obtain the names ofall VFSes in the VFS stack. The names are of all VFS shims and thefinal bottom-level VFS are written into memory obtained fromsqlite3_malloc() and the result is stored in the char* variablethat the fourth parameter of sqlite3_file_control() points to.The caller is responsible for freeing the memory when done. As withall file-control actions, there is no guarantee that this will actuallydo anything. Callers should initialize the char* variable to a NULLpointer in case this file-control is not implemented. This file-controlis intended for diagnostic use only.
Virtual Table Constraint Operator Codes#define SQLITE_INDEX_CONSTRAINT_EQ 2#define SQLITE_INDEX_CONSTRAINT_GT 4#define SQLITE_INDEX_CONSTRAINT_LE 8#define SQLITE_INDEX_CONSTRAINT_LT 16#define SQLITE_INDEX_CONSTRAINT_GE 32#define SQLITE_INDEX_CONSTRAINT_MATCH 64
These macros defined the allowed values for thesqlite3_index_info.aConstraint[].op field. Each value representsan operator that is part of a constraint term in the wHERE clause ofa query that uses a virtual table.
Device Characteristics#define SQLITE_IOCAP_ATOMIC 0x00000001#define SQLITE_IOCAP_ATOMIC512 0x00000002#define SQLITE_IOCAP_ATOMIC1K 0x00000004#define SQLITE_IOCAP_ATOMIC2K 0x00000008#define SQLITE_IOCAP_ATOMIC4K 0x00000010#define SQLITE_IOCAP_ATOMIC8K 0x00000020#define SQLITE_IOCAP_ATOMIC16K 0x00000040#define SQLITE_IOCAP_ATOMIC32K 0x00000080#define SQLITE_IOCAP_ATOMIC64K 0x00000100#define SQLITE_IOCAP_SAFE_APPEND 0x00000200#define SQLITE_IOCAP_SEQUENTIAL 0x00000400#define SQLITE_IOCAP_UNDELETABLE_WHEN_OPEN 0x00000800#define SQLITE_IOCAP_POWERSAFE_OVERWRITE 0x00001000
The xDeviceCharacteristics method of the sqlite3_io_methodsobject returns an integer which is a vector of the thesebit values expressing I/O characteristics of the mass storagedevice that holds the file that the sqlite3_io_methodsrefers to.
The SQLITE_IOCAP_ATOMIC property means that all writes ofany size are atomic. The SQLITE_IOCAP_ATOMICnnn valuesmean that writes of blocks that are nnn bytes in size andare aligned to an address which is an integer multiple ofnnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value meansthat when data is appended to a file, the data is appendedfirst then the size of the file is extended, never the otherway around. The SQLITE_IOCAP_SEQUENTIAL property means thatinformation is written to disk in the same order as callsto xWrite(). The SQLITE_IOCAP_POWERSAFE_OVERWRITE property means thatafter reboot following a crash or power loss, the only bytes in afile that were written at the application level might have changedand that adjacent bytes, even bytes within the same sector areguaranteed to be unchanged.
File Locking Levels#define SQLITE_LOCK_NONE 0#define SQLITE_LOCK_SHARED 1#define SQLITE_LOCK_RESERVED 2#define SQLITE_LOCK_PENDING 3#define SQLITE_LOCK_EXCLUSIVE 4
SQLite uses one of these integer values as the secondargument to calls it makes to the xLock() and xUnlock() methodsof an sqlite3_io_methods object.
Mutex Types#define SQLITE_MUTEX_FAST 0#define SQLITE_MUTEX_RECURSIVE 1#define SQLITE_MUTEX_STATIC_MASTER 2#define SQLITE_MUTEX_STATIC_MEM 3 /* sqlite3_malloc() */#define SQLITE_MUTEX_STATIC_MEM2 4 /* NOT USED */#define SQLITE_MUTEX_STATIC_OPEN 4 /* sqlite3BtreeOpen() */#define SQLITE_MUTEX_STATIC_PRNG 5 /* sqlite3_random() */#define SQLITE_MUTEX_STATIC_LRU 6 /* lru page list */#define SQLITE_MUTEX_STATIC_LRU2 7 /* NOT USED */#define SQLITE_MUTEX_STATIC_PMEM 7 /* sqlite3PageMalloc() */
The sqlite3_mutex_alloc() interface takes a single argumentwhich is one of these integer constants.
The set of static mutexes may change from one SQLite release to thenext. Applications that override the built-in mutex logic must beprepared to accommodate additional static mutexes.
Flags For File Open Operations#define SQLITE_OPEN_READONLY 0x00000001 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_READWRITE 0x00000002 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_CREATE 0x00000004 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_DELETEONCLOSE 0x00000008 /* VFS only */#define SQLITE_OPEN_EXCLUSIVE 0x00000010 /* VFS only */#define SQLITE_OPEN_AUTOPROXY 0x00000020 /* VFS only */#define SQLITE_OPEN_URI 0x00000040 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_MAIN_DB 0x00000100 /* VFS only */#define SQLITE_OPEN_TEMP_DB 0x00000200 /* VFS only */#define SQLITE_OPEN_TRANSIENT_DB 0x00000400 /* VFS only */#define SQLITE_OPEN_MAIN_JOURNAL 0x00000800 /* VFS only */#define SQLITE_OPEN_TEMP_JOURNAL 0x00001000 /* VFS only */#define SQLITE_OPEN_SUBJOURNAL 0x00002000 /* VFS only */#define SQLITE_OPEN_MASTER_JOURNAL 0x00004000 /* VFS only */#define SQLITE_OPEN_NOMUTEX 0x00008000 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_FULLMUTEX 0x00010000 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_SHAREDCACHE 0x00020000 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_PRIVATECACHE 0x00040000 /* Ok for sqlite3_open_v2() */#define SQLITE_OPEN_WAL 0x00080000 /* VFS only */
These bit values are intended for use in the3rd parameter to the sqlite3_open_v2() interface andin the 4th parameter to the sqlite3_vfs.xOpen method.
Flags for the xShmLock VFS method#define SQLITE_SHM_UNLOCK 1#define SQLITE_SHM_LOCK 2#define SQLITE_SHM_SHARED 4#define SQLITE_SHM_EXCLUSIVE 8
These integer constants define the various locking operationsallowed by the xShmLock method of sqlite3_io_methods. Thefollowing are the only legal combinations of flags to thexShmLock method:
SQLITE_SHM_LOCK | SQLITE_SHM_SHARED SQLITE_SHM_LOCK | SQLITE_SHM_EXCLUSIVE SQLITE_SHM_UNLOCK | SQLITE_SHM_SHARED SQLITE_SHM_UNLOCK | SQLITE_SHM_EXCLUSIVEWhen unlocking, the same SHARED or EXCLUSIVE flag must be supplied aswas given no the corresponding lock.
The xShmLock method can transition between unlocked and SHARED orbetween unlocked and EXCLUSIVE. It cannot transition between SHAREDand EXCLUSIVE.
Compile-Time Library Version Numbers#define SQLITE_VERSION "3.7.10"#define SQLITE_VERSION_NUMBER 3007010#define SQLITE_SOURCE_ID "2012-01-16 16:56:31 93aa17d866873e11dde5ffbefe74497f229977c1"
The SQLITE_VERSION C preprocessor macro in the sqlite3.h headerevaluates to a string literal that is the SQLite version in theformat "X.Y.Z" where X is the major version number (always 3 forSQLite3) and Y is the minor version number and Z is the release number.The SQLITE_VERSION_NUMBER C preprocessor macro resolves to an integerwith the value (X*1000000 + Y*1000 + Z) where X, Y, and Z are the samenumbers used in SQLITE_VERSION.The SQLITE_VERSION_NUMBER for any given release of SQLite will alsobe larger than the release from which it is derived. Either Y willbe held constant and Z will be incremented or else Y will be incrementedand Z will be reset to zero.
Since version 3.6.18, SQLite source code has been stored in theFossil configuration managementsystem. The SQLITE_SOURCE_ID macro evaluates toa string which identifies a particular check-in of SQLitewithin its configuration management system. The SQLITE_SOURCE_IDstring contains the date and time of the check-in (UTC) and an SHA1hash of the entire source tree.
See also: sqlite3_libversion(),sqlite3_libversion_number(), sqlite3_sourceid(),sqlite_version() and sqlite_source_id().
Constants Defining Special Destructor Behaviortypedef void (*sqlite3_destructor_type)(void*);#define SQLITE_STATIC ((sqlite3_destructor_type)0)#define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1)
These are special values for the destructor that is passed in as thefinal argument to routines like sqlite3_result_blob(). If the destructorargument is SQLITE_STATIC, it means that the content pointer is constantand will never change. It does not need to be destroyed. TheSQLITE_TRANSIENT value means that the content will likely change inthe near future and that SQLite should make its own private copy ofthe content before returning.
The typedef is necessary to work around problems in certainC++ compilers. See ticket #2191.
Status Parameters#define SQLITE_STATUS_MEMORY_USED 0#define SQLITE_STATUS_PAGECACHE_USED 1#define SQLITE_STATUS_PAGECACHE_OVERFLOW 2#define SQLITE_STATUS_SCRATCH_USED 3#define SQLITE_STATUS_SCRATCH_OVERFLOW 4#define SQLITE_STATUS_MALLOC_SIZE 5#define SQLITE_STATUS_PARSER_STACK 6#define SQLITE_STATUS_PAGECACHE_SIZE 7#define SQLITE_STATUS_SCRATCH_SIZE 8#define SQLITE_STATUS_MALLOC_COUNT 9
These integer constants designate various run-time status parametersthat can be returned by sqlite3_status().
SQLITE_STATUS_MEMORY_USEDThis parameter is the current amount of memory checked outusing sqlite3_malloc(), either directly or indirectly. Thefigure includes calls made to sqlite3_malloc() by the applicationand internal memory usage by the SQLite library. Scratch memorycontrolled by SQLITE_CONFIG_SCRATCH and auxiliary page-cachememory controlled by SQLITE_CONFIG_PAGECACHE is not included inthis parameter. The amount returned is the sum of the allocationsizes as reported by the xSize method in sqlite3_mem_methods.SQLITE_STATUS_MALLOC_SIZEThis parameter records the largest memory allocation requesthanded to sqlite3_malloc() or sqlite3_realloc() (or theirinternal equivalents). Only the value returned in the*pHighwater parameter to sqlite3_status() is of interest.The value written into the *pCurrent parameter is undefined.
SQLITE_STATUS_MALLOC_COUNTThis parameter records the number of separate memory allocationscurrently checked out.
SQLITE_STATUS_PAGECACHE_USEDThis parameter returns the number of pages used out of thepagecache memory allocator that was configured usingSQLITE_CONFIG_PAGECACHE. Thevalue returned is in pages, not in bytes.SQLITE_STATUS_PAGECACHE_OVERFLOWThis parameter returns the number of bytes of page cacheallocation which could not be satisfied by the SQLITE_CONFIG_PAGECACHEbuffer and where forced to overflow to sqlite3_malloc(). Thereturned value includes allocations that overflowed because theywhere too large (they were larger than the "sz" parameter toSQLITE_CONFIG_PAGECACHE) and allocations that overflowed becauseno space was left in the page cache.
SQLITE_STATUS_PAGECACHE_SIZEThis parameter records the largest memory allocation requesthanded to pagecache memory allocator. Only the value returned in the*pHighwater parameter to sqlite3_status() is of interest.The value written into the *pCurrent parameter is undefined.
SQLITE_STATUS_SCRATCH_USEDThis parameter returns the number of allocations used out of thescratch memory allocator configured usingSQLITE_CONFIG_SCRATCH. The value returned is in allocations, notin bytes. Since a single thread may only have one scratch allocationoutstanding at time, this parameter also reports the number of threadsusing scratch memory at the same time.
SQLITE_STATUS_SCRATCH_OVERFLOWThis parameter returns the number of bytes of scratch memoryallocation which could not be satisfied by the SQLITE_CONFIG_SCRATCHbuffer and where forced to overflow to sqlite3_malloc(). The valuesreturned include overflows because the requested allocation was toolarger (that is, because the requested allocation was larger than the"sz" parameter to SQLITE_CONFIG_SCRATCH) and because no scratch bufferslots were available.
SQLITE_STATUS_SCRATCH_SIZEThis parameter records the largest memory allocation requesthanded to scratch memory allocator. Only the value returned in the*pHighwater parameter to sqlite3_status() is of interest.The value written into the *pCurrent parameter is undefined.
SQLITE_STATUS_PARSER_STACKThis parameter records the deepest parser stack. It is onlymeaningful if SQLite is compiled with YYTRACKMAXSTACKDEPTH.
New status parameters may be added from time to time.
Synchronization Type Flags#define SQLITE_SYNC_NORMAL 0x00002#define SQLITE_SYNC_FULL 0x00003#define SQLITE_SYNC_DATAONLY 0x00010
When SQLite invokes the xSync() method of ansqlite3_io_methods object it uses a combination ofthese integer values as the second argument.
When the SQLITE_SYNC_DATAONLY flag is used, it means that thesync operation only needs to flush data to mass storage. Inodeinformation need not be flushed. If the lower four bits of the flagequal SQLITE_SYNC_NORMAL, that means to use normal fsync() semantics.If the lower four bits equal SQLITE_SYNC_FULL, that meansto use Mac OS X style fullsync instead of fsync().
Do not confuse the SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flagswith the PRAGMA synchronous=NORMAL and PRAGMA synchronous=FULLsettings. The synchronous pragma determines when calls to thexSync VFS method occur and applies uniformly across all platforms.The SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flags determine howenergetic or rigorous or forceful the sync operations are andonly make a difference on Mac OSX for the default SQLite code.(Third-party VFS implementations might also make the distinctionbetween SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL, but among theoperating systems natively supported by SQLite, only Mac OSXcares about the difference.)
Testing Interface Operation Codes#define SQLITE_TESTCTRL_FIRST 5#define SQLITE_TESTCTRL_PRNG_SAVE 5#define SQLITE_TESTCTRL_PRNG_RESTORE 6#define SQLITE_TESTCTRL_PRNG_RESET 7#define SQLITE_TESTCTRL_BITVEC_TEST 8#define SQLITE_TESTCTRL_FAULT_INSTALL 9#define SQLITE_TESTCTRL_BENIGN_MALLOC_HOOKS 10#define SQLITE_TESTCTRL_PENDING_BYTE 11#define SQLITE_TESTCTRL_ASSERT 12#define SQLITE_TESTCTRL_ALWAYS 13#define SQLITE_TESTCTRL_RESERVE 14#define SQLITE_TESTCTRL_OPTIMIZATIONS 15#define SQLITE_TESTCTRL_ISKEYWORD 16#define SQLITE_TESTCTRL_SCRATCHMALLOC 17#define SQLITE_TESTCTRL_LOCALTIME_FAULT 18#define SQLITE_TESTCTRL_EXPLAIN_STMT 19#define SQLITE_TESTCTRL_LAST 19
These constants are the valid operation code parameters usedas the first argument to sqlite3_test_control().
These parameters and their meanings are subject to changewithout notice. These values are for testing purposes only.Applications should not use any of these parameters or thesqlite3_test_control() interface.
Run-Time Limit Categories#define SQLITE_LIMIT_LENGTH 0#define SQLITE_LIMIT_SQL_LENGTH 1#define SQLITE_LIMIT_COLUMN 2#define SQLITE_LIMIT_EXPR_DEPTH 3#define SQLITE_LIMIT_COMPOUND_SELECT 4#define SQLITE_LIMIT_VDBE_OP 5#define SQLITE_LIMIT_FUNCTION_ARG 6#define SQLITE_LIMIT_ATTACHED 7#define SQLITE_LIMIT_LIKE_PATTERN_LENGTH 8#define SQLITE_LIMIT_VARIABLE_NUMBER 9#define SQLITE_LIMIT_TRIGGER_DEPTH 10
These constants define various performance limitsthat can be lowered at run-time using sqlite3_limit().The synopsis of the meanings of the various limits is shown below.Additional information is available at Limits in SQLite.
SQLITE_LIMIT_LENGTHThe maximum size of any string or BLOB or table row, in bytes.SQLITE_LIMIT_SQL_LENGTHThe maximum length of an SQL statement, in bytes.
SQLITE_LIMIT_COLUMNThe maximum number of columns in a table definition or in theresult set of a SELECT or the maximum number of columns in an indexor in an ORDER BY or GROUP BY clause.
SQLITE_LIMIT_EXPR_DEPTHThe maximum depth of the parse tree on any expression.
SQLITE_LIMIT_COMPOUND_SELECTThe maximum number of terms in a compound SELECT statement.
SQLITE_LIMIT_VDBE_OPThe maximum number of instructions in a virtual machine programused to implement an SQL statement. This limit is not currentlyenforced, though that might be added in some future release ofSQLite.
SQLITE_LIMIT_FUNCTION_ARGThe maximum number of arguments on a function.
SQLITE_LIMIT_ATTACHEDThe maximum number of attached databases.SQLITE_LIMIT_LIKE_PATTERN_LENGTHThe maximum length of the pattern argument to the LIKE orGLOB operators.SQLITE_LIMIT_VARIABLE_NUMBERThe maximum index number of any parameter in an SQL statement.
SQLITE_LIMIT_TRIGGER_DEPTHThe maximum depth of recursion for triggers.Status Parameters for database connections
#define SQLITE_DBSTATUS_LOOKASIDE_USED 0#define SQLITE_DBSTATUS_CACHE_USED 1#define SQLITE_DBSTATUS_SCHEMA_USED 2#define SQLITE_DBSTATUS_STMT_USED 3#define SQLITE_DBSTATUS_LOOKASIDE_HIT 4#define SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZE 5#define SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL 6#define SQLITE_DBSTATUS_CACHE_HIT 7#define SQLITE_DBSTATUS_CACHE_MISS 8#define SQLITE_DBSTATUS_MAX 8 /* Largest defined DBSTATUS */
These constants are the available integer "verbs" that can be passed asthe second argument to the sqlite3_db_status() interface.
New verbs may be added in future releases of SQLite. Existing verbsmight be discontinued. Applications should check the return code fromsqlite3_db_status() to make sure that the call worked.The sqlite3_db_status() interface will return a non-zero error codeif a discontinued or unsupported verb is invoked.
SQLITE_DBSTATUS_LOOKASIDE_USEDThis parameter returns the number of lookaside memory slots currentlychecked out.SQLITE_DBSTATUS_LOOKASIDE_HITThis parameter returns the number malloc attempts that weresatisfied using lookaside memory. Only the high-water value is meaningful;the current value is always zero.SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZEThis parameter returns the number malloc attempts that might havebeen satisfied using lookaside memory but failed due to the amount ofmemory requested being larger than the lookaside slot size.Only the high-water value is meaningful;the current value is always zero.SQLITE_DBSTATUS_LOOKASIDE_MISS_FULLThis parameter returns the number malloc attempts that might havebeen satisfied using lookaside memory but failed due to all lookasidememory already being in use.Only the high-water value is meaningful;the current value is always zero.
SQLITE_DBSTATUS_CACHE_USEDThis parameter returns the approximate number of of bytes of heapmemory used by all pager caches associated with the database connection.The highwater mark associated with SQLITE_DBSTATUS_CACHE_USED is always 0.
SQLITE_DBSTATUS_SCHEMA_USEDThis parameter returns the approximate number of of bytes of heapmemory used to store the schema for all databases associatedwith the connection - main, temp, and any ATTACH-ed databases.The full amount of memory used by the schemas is reported, even if theschema memory is shared with other database connections due toshared cache mode being enabled.The highwater mark associated with SQLITE_DBSTATUS_SCHEMA_USED is always 0.
SQLITE_DBSTATUS_STMT_USEDThis parameter returns the approximate number of of bytes of heapand lookaside memory used by all prepared statements associated withthe database connection.The highwater mark associated with SQLITE_DBSTATUS_STMT_USED is always 0.
SQLITE_DBSTATUS_CACHE_HITThis parameter returns the number of pager cache hits that haveoccurred. The highwater mark associated with SQLITE_DBSTATUS_CACHE_HITis always 0.
SQLITE_DBSTATUS_CACHE_MISSThis parameter returns the number of pager cache misses that haveoccurred. The highwater mark associated with SQLITE_DBSTATUS_CACHE_MISSis always 0.Status Parameters for prepared statements
#define SQLITE_STMTSTATUS_FULLSCAN_STEP 1#define SQLITE_STMTSTATUS_SORT 2#define SQLITE_STMTSTATUS_AUTOINDEX 3
These preprocessor macros define integer codes that name countervalues associated with the sqlite3_stmt_status() interface.The meanings of the various counters are as follows:
SQLITE_STMTSTATUS_FULLSCAN_STEPThis is the number of times that SQLite has stepped forward ina table as part of a full table scan. Large numbers for this countermay indicate opportunities for performance improvement throughcareful use of indices.SQLITE_STMTSTATUS_SORTThis is the number of sort operations that have occurred.A non-zero value in this counter may indicate an opportunity toimprovement performance through careful use of indices.
SQLITE_STMTSTATUS_AUTOINDEXThis is the number of rows inserted into transient indices thatwere created automatically in order to help joins run faster.A non-zero value in this counter may indicate an opportunity toimprovement performance by adding permanent indices that do notneed to be reinitialized each time the statement is run.64-Bit Integer Types
#ifdef SQLITE_INT64_TYPE typedef SQLITE_INT64_TYPE sqlite_int64; typedef unsigned SQLITE_INT64_TYPE sqlite_uint64;#elif defined(_MSC_VER) || defined(__BORLANDC__) typedef __int64 sqlite_int64; typedef unsigned __int64 sqlite_uint64;#else typedef long long int sqlite_int64; typedef unsigned long long int sqlite_uint64;#endiftypedef sqlite_int64 sqlite3_int64;typedef sqlite_uint64 sqlite3_uint64;
Because there is no cross-platform way to specify 64-bit integer typesSQLite includes typedefs for 64-bit signed and unsigned integers.
The sqlite3_int64 and sqlite3_uint64 are the preferred type definitions.The sqlite_int64 and sqlite_uint64 types are supported for backwardscompatibility only.
The sqlite3_int64 and sqlite_int64 types can store integer valuesbetween -9223372036854775808 and +9223372036854775807 inclusive. Thesqlite3_uint64 and sqlite_uint64 types can store integer valuesbetween 0 and +18446744073709551615 inclusive.
Virtual Table Objectstruct sqlite3_module { int iVersion; int (*xCreate)(sqlite3*, void *pAux, int argc, const char *const*argv, sqlite3_vtab **ppVTab, char**); int (*xConnect)(sqlite3*, void *pAux, int argc, const char *const*argv, sqlite3_vtab **ppVTab, char**); int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*); int (*xDisconnect)(sqlite3_vtab *pVTab); int (*xDestroy)(sqlite3_vtab *pVTab); int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor); int (*xClose)(sqlite3_vtab_cursor*); int (*xFilter)(sqlite3_vtab_cursor*, int idxNum, const char *idxStr, int argc, sqlite3_value **argv); int (*xNext)(sqlite3_vtab_cursor*); int (*xEof)(sqlite3_vtab_cursor*); int (*xColumn)(sqlite3_vtab_cursor*, sqlite3_context*, int); int (*xRowid)(sqlite3_vtab_cursor*, sqlite3_int64 *pRowid); int (*xUpdate)(sqlite3_vtab *, int, sqlite3_value **, sqlite3_int64 *); int (*xBegin)(sqlite3_vtab *pVTab); int (*xSync)(sqlite3_vtab *pVTab); int (*xCommit)(sqlite3_vtab *pVTab); int (*xRollback)(sqlite3_vtab *pVTab); int (*xFindFunction)(sqlite3_vtab *pVtab, int nArg, const char *zName, void (**pxFunc)(sqlite3_context*,int,sqlite3_value**), void **ppArg); int (*xRename)(sqlite3_vtab *pVtab, const char *zNew); /* The methods above are in version 1 of the sqlite_module object. Those ** below are for version 2 and greater. */ int (*xSavepoint)(sqlite3_vtab *pVTab, int); int (*xRelease)(sqlite3_vtab *pVTab, int); int (*xRollbackTo)(sqlite3_vtab *pVTab, int);};This structure, sometimes called a "virtual table module",defines the implementation of a virtual tables.This structure consists mostly of methods for the module.
A virtual table module is created by filling in a persistentinstance of this structure and passing a pointer to that instanceto sqlite3_create_module() or sqlite3_create_module_v2().The registration remains valid until it is replaced by a differentmodule or until the database connection closes. The contentof this structure must not change while it is registered withany database connection.
Virtual Table Cursor Objectstruct sqlite3_vtab_cursor { sqlite3_vtab *pVtab; /* Virtual table of this cursor */ /* Virtual table implementations will typically add additional fields */};Every virtual table module implementation uses a subclass of thefollowing structure to describe cursors that point into thevirtual table and are usedto loop through the virtual table. Cursors are created using thexOpen method of the module and are destroyedby the xClose method. Cursors are usedby the xFilter, xNext, xEof, xColumn, and xRowid methodsof the module. Each module implementation will definethe content of a cursor structure to suit its own needs.
This superclass exists in order to define fields of the cursor thatare common to all implementations.
A Handle To An Open BLOBtypedef struct sqlite3_blob sqlite3_blob;
An instance of this object represents an open BLOB on whichincremental BLOB I/O can be performed.Objects of this type are created by sqlite3_blob_open()and destroyed by sqlite3_blob_close().The sqlite3_blob_read() and sqlite3_blob_write() interfacescan be used to read or write small subsections of the BLOB.The sqlite3_blob_bytes() interface returns the size of the BLOB in bytes.
Database Connection Handletypedef struct sqlite3 sqlite3;
Each open SQLite database is represented by a pointer to an instance ofthe opaque structure named "sqlite3". It is useful to think of an sqlite3pointer as an object. The sqlite3_open(), sqlite3_open16(), andsqlite3_open_v2() interfaces are its constructors, and sqlite3_close()is its destructor. There are many other interfaces (such assqlite3_prepare_v2(), sqlite3_create_function(), andsqlite3_busy_timeout() to name but three) that are methods on ansqlite3 object.
Application Defined Page Cache.typedef struct sqlite3_pcache_methods2 sqlite3_pcache_methods2;struct sqlite3_pcache_methods2 { int iVersion; void *pArg; int (*xInit)(void*); void (*xShutdown)(void*); sqlite3_pcache *(*xCreate)(int szPage, int szExtra, int bPurgeable); void (*xCachesize)(sqlite3_pcache*, int nCachesize); int (*xPagecount)(sqlite3_pcache*); sqlite3_pcache_page *(*xFetch)(sqlite3_pcache*, unsigned key, int createFlag); void (*xUnpin)(sqlite3_pcache*, sqlite3_pcache_page*, int discard); void (*xRekey)(sqlite3_pcache*, sqlite3_pcache_page*, unsigned oldKey, unsigned newKey); void (*xTruncate)(sqlite3_pcache*, unsigned iLimit); void (*xDestroy)(sqlite3_pcache*); void (*xShrink)(sqlite3_pcache*);};The sqlite3_config(SQLITE_CONFIG_PCACHE2, ...) interface canregister an alternative page cache implementation by passing in aninstance of the sqlite3_pcache_methods2 structure.In many applications, most of the heap memory allocated bySQLite is used for the page cache.By implementing acustom page cache using this API, an application can better controlthe amount of memory consumed by SQLite, the way in whichthat memory is allocated and released, and the policies used todetermine exactly which parts of a database file are cached and forhow long.
The alternative page cache mechanism is anextreme measure that is only needed by the most demanding applications.The built-in page cache is recommended for most uses.
The contents of the sqlite3_pcache_methods2 structure are copied to aninternal buffer by SQLite within the call to sqlite3_config. Hencethe application may discard the parameter after the call tosqlite3_config() returns.
The xInit() method is called once for each effectivecall to sqlite3_initialize()(usually only once during the lifetime of the process). The xInit()method is passed a copy of the sqlite3_pcache_methods2.pArg value.The intent of the xInit() method is to set up global data structuresrequired by the custom page cache implementation.If the xInit() method is NULL, then thebuilt-in default page cache is used instead of the application definedpage cache.
The xShutdown() method is called by sqlite3_shutdown().It can be used to clean upany outstanding resources before process shutdown, if required.The xShutdown() method may be NULL.
SQLite automatically serializes calls to the xInit method,so the xInit method need not be threadsafe. ThexShutdown method is only called from sqlite3_shutdown() so it doesnot need to be threadsafe either. All other methods must be threadsafein multithreaded applications.
SQLite will never invoke xInit() more than once without an interveningcall to xShutdown().
SQLite invokes the xCreate() method to construct a new cache instance.SQLite will typically create one cache instance for each open database file,though this is not guaranteed. Thefirst parameter, szPage, is the size in bytes of the pages that mustbe allocated by the cache. szPage will always a power of two. Thesecond parameter szExtra is a number of bytes of extra storageassociated with each page cache entry. The szExtra parameter willa number less than 250. SQLite will use theextra szExtra bytes on each page to store metadata about the underlyingdatabase page on disk. The value passed into szExtra dependson the SQLite version, the target platform, and how SQLite was compiled.The third argument to xCreate(), bPurgeable, is true if the cache beingcreated will be used to cache database pages of a file stored on disk, orfalse if it is used for an in-memory database. The cache implementationdoes not have to do anything special based with the value of bPurgeable;it is purely advisory. On a cache where bPurgeable is false, SQLite willnever invoke xUnpin() except to deliberately delete a page.In other words, calls to xUnpin() on a cache with bPurgeable set tofalse will always have the "discard" flag set to true.Hence, a cache created with bPurgeable false willnever contain any unpinned pages.
The xCachesize() method may be called at any time by SQLite to set thesuggested maximum cache-size (number of pages stored by) the cacheinstance passed as the first argument. This is the value configured usingthe SQLite "PRAGMA cache_size" command. As with the bPurgeableparameter, the implementation is not required to do anything with thisvalue; it is advisory only.
The xPagecount() method must return the number of pages currentlystored in the cache, both pinned and unpinned.
The xFetch() method locates a page in the cache and returns a pointer toan sqlite3_pcache_page object associated with that page, or a NULL pointer.The pBuf element of the returned sqlite3_pcache_page object will be apointer to a buffer of szPage bytes used to store the content of asingle database page. The pExtra element of sqlite3_pcache_page will bea pointer to the szExtra bytes of extra storage that SQLite has requestedfor each entry in the page cache.
The page to be fetched is determined by the key. The minimum key valueis 1. After it has been retrieved using xFetch, the page is consideredto be "pinned".
If the requested page is already in the page cache, then the page cacheimplementation must return a pointer to the page buffer with its contentintact. If the requested page is not already in the cache, then thecache implementation should use the value of the createFlagparameter to help it determined what action to take:
createFlag Behaviour when page is not already in cache 0 Do not allocate a new page. Return NULL. 1 Allocate a new page if it easy and convenient to do so.Otherwise return NULL. 2 Make every effort to allocate a new page. Only returnNULL if allocating a new page is effectively impossible.SQLite will normally invoke xFetch() with a createFlag of 0 or 1. SQLitewill only use a createFlag of 2 after a prior call with a createFlag of 1failed. In between the to xFetch() calls, SQLite mayattempt to unpin one or more cache pages by spilling the content ofpinned pages to disk and synching the operating system disk cache.
xUnpin() is called by SQLite with a pointer to a currently pinned pageas its second argument. If the third parameter, discard, is non-zero,then the page must be evicted from the cache.If the discard parameter iszero, then the page may be discarded or retained at the discretion ofpage cache implementation. The page cache implementationmay choose to evict unpinned pages at any time.
The cache must not perform any reference counting. A singlecall to xUnpin() unpins the page regardless of the number of prior callsto xFetch().
The xRekey() method is used to change the key value associated with thepage passed as the second argument. If the cachepreviously contains an entry associated with newKey, it must bediscarded. Any prior cache entry associated with newKey is guaranteed notto be pinned.
When SQLite calls the xTruncate() method, the cache must discard allexisting cache entries with page numbers (keys) greater than or equalto the value of the iLimit parameter passed to xTruncate(). If anyof these pages are pinned, they are implicitly unpinned, meaning thatthey can be safely discarded.
The xDestroy() method is used to delete a cache allocated by xCreate().All resources associated with the specified cache should be freed. Aftercalling the xDestroy() method, SQLite considers the sqlite3_pcache*handle invalid, and will not use it with any other sqlite3_pcache_methods2functions.
SQLite invokes the xShrink() method when it wants the page cache tofree up as much of heap memory as possible. The page cache implementationis not obligated to free any memory, but well-behaved implementations shoulddo their best.
SQL Statement Objecttypedef struct sqlite3_stmt sqlite3_stmt;
An instance of this object represents a single SQL statement.This object is variously known as a "prepared statement" or a"compiled SQL statement" or simply as a "statement".
The life of a statement object goes something like this:
Refer to documentation on individual methods above for additionalinformation.
Dynamically Typed Value Objecttypedef struct Mem sqlite3_value;
SQLite uses the sqlite3_value object to represent all valuesthat can be stored in a database table. SQLite uses dynamic typingfor the values it stores. Values stored in sqlite3_value objectscan be integers, floating point values, strings, BLOBs, or NULL.
An sqlite3_value object may be either "protected" or "unprotected".Some interfaces require a protected sqlite3_value. Other interfaceswill accept either a protected or an unprotected sqlite3_value.Every interface that accepts sqlite3_value arguments specifieswhether or not it requires a protected sqlite3_value.
The terms "protected" and "unprotected" refer to whether or nota mutex is held. An internal mutex is held for a protectedsqlite3_value object but no mutex is held for an unprotectedsqlite3_value object. If SQLite is compiled to be single-threaded(with SQLITE_THREADSAFE=0 and with sqlite3_threadsafe() returning 0)or if SQLite is run in one of reduced mutex modesSQLITE_CONFIG_SINGLETHREAD or SQLITE_CONFIG_MULTITHREADthen there is no distinction between protected and unprotectedsqlite3_value objects and they can be used interchangeably. However,for maximum code portability it is recommended that applicationsstill make the distinction between protected and unprotectedsqlite3_value objects even when not strictly required.
The sqlite3_value objects that are passed as parameters into theimplementation of application-defined SQL functions are protected.The sqlite3_value object returned bysqlite3_column_value() is unprotected.Unprotected sqlite3_value objects may only be used withsqlite3_result_value() and sqlite3_bind_value().The sqlite3_value_type() family ofinterfaces require protected sqlite3_value objects.
Deprecated Functions#ifndef SQLITE_OMIT_DEPRECATEDint sqlite3_aggregate_count(sqlite3_context*);int sqlite3_expired(sqlite3_stmt*);int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*);int sqlite3_global_recover(void);void sqlite3_thread_cleanup(void);int sqlite3_memory_alarm(void(*)(void*,sqlite3_int64,int),void*,sqlite3_int64);#endif
These functions are deprecated. In order to maintainbackwards compatibility with older code, these functions continueto be supported. However, new applications should avoidthe use of these functions. To help encourage people to avoidusing these functions, we are not going to tell you what they do.
Online Backup API.sqlite3_backup *sqlite3_backup_init( sqlite3 *pDest, /* Destination database handle */ const char *zDestName, /* Destination database name */ sqlite3 *pSource, /* Source database handle */ const char *zSourceName /* Source database name */);int sqlite3_backup_step(sqlite3_backup *p, int nPage);int sqlite3_backup_finish(sqlite3_backup *p);int sqlite3_backup_remaining(sqlite3_backup *p);int sqlite3_backup_pagecount(sqlite3_backup *p);
The backup API copies the content of one database into another.It is useful either for creating backups of databases orfor copying in-memory databases to or from persistent files.
See Also: Using the SQLite Online Backup API
SQLite holds a write transaction open on the destination database filefor the duration of the backup operation.The source database is read-locked only while it is being read;it is not locked continuously for the entire backup operation.Thus, the backup may be performed on a live source database withoutpreventing other database connections fromreading or writing to the source database while the backup is underway.
To perform a backup operation:
There should be exactly one call to sqlite3_backup_finish() for eachsuccessful call to sqlite3_backup_init().
sqlite3_backup_init()
The D and N arguments to sqlite3_backup_init(D,N,S,M) are thedatabase connection associated with the destination databaseand the database name, respectively.The database name is "main" for the main database, "temp" for thetemporary database, or the name specified after the AS keyword inan ATTACH statement for an attached database.The S and M arguments passed tosqlite3_backup_init(D,N,S,M) identify the database connectionand database name of the source database, respectively.The source and destination database connections (parameters S and D)must be different or else sqlite3_backup_init(D,N,S,M) will fail withan error.
If an error occurs within sqlite3_backup_init(D,N,S,M), then NULL isreturned and an error code and error message are stored in thedestination database connection D.The error code and message for the failed call to sqlite3_backup_init()can be retrieved using the sqlite3_errcode(), sqlite3_errmsg(), and/orsqlite3_errmsg16() functions.A successful call to sqlite3_backup_init() returns a pointer to ansqlite3_backup object.The sqlite3_backup object may be used with the sqlite3_backup_step() andsqlite3_backup_finish() functions to perform the specified backupoperation.
sqlite3_backup_step()
Function sqlite3_backup_step(B,N) will copy up to N pages betweenthe source and destination databases specified by sqlite3_backup object B.If N is negative, all remaining source pages are copied.If sqlite3_backup_step(B,N) successfully copies N pages and thereare still more pages to be copied, then the function returns SQLITE_OK.If sqlite3_backup_step(B,N) successfully finishes copying all pagesfrom source to destination, then it returns SQLITE_DONE.If an error occurs while running sqlite3_backup_step(B,N),then an error code is returned. As well as SQLITE_OK andSQLITE_DONE, a call to sqlite3_backup_step() may return SQLITE_READONLY,SQLITE_NOMEM, SQLITE_BUSY, SQLITE_LOCKED, or anSQLITE_IOERR_XXX extended error code.
The sqlite3_backup_step() might return SQLITE_READONLY if
If sqlite3_backup_step() cannot obtain a required file-system lock, thenthe busy-handler functionis invoked (if one is specified). If thebusy-handler returns non-zero before the lock is available, thenSQLITE_BUSY is returned to the caller. In this case the call tosqlite3_backup_step() can be retried later. If the sourcedatabase connectionis being used to write to the source database when sqlite3_backup_step()is called, then SQLITE_LOCKED is returned immediately. Again, in thiscase the call to sqlite3_backup_step() can be retried later on. IfSQLITE_IOERR_XXX, SQLITE_NOMEM, orSQLITE_READONLY is returned, thenthere is no point in retrying the call to sqlite3_backup_step(). Theseerrors are considered fatal. The application must acceptthat the backup operation has failed and pass the backup operation handleto the sqlite3_backup_finish() to release associated resources.
The first call to sqlite3_backup_step() obtains an exclusive lockon the destination file. The exclusive lock is not released until eithersqlite3_backup_finish() is called or the backup operation is completeand sqlite3_backup_step() returns SQLITE_DONE. Every call tosqlite3_backup_step() obtains a shared lock on the source database thatlasts for the duration of the sqlite3_backup_step() call.Because the source database is not locked between calls tosqlite3_backup_step(), the source database may be modified mid-waythrough the backup process. If the source database is modified by anexternal process or via a database connection other than the one beingused by the backup operation, then the backup will be automaticallyrestarted by the next call to sqlite3_backup_step(). If the sourcedatabase is modified by the using the same database connection as is usedby the backup operation, then the backup database is automaticallyupdated at the same time.
sqlite3_backup_finish()
When sqlite3_backup_step() has returned SQLITE_DONE, or when theapplication wishes to abandon the backup operation, the applicationshould destroy the sqlite3_backup by passing it to sqlite3_backup_finish().The sqlite3_backup_finish() interfaces releases allresources associated with the sqlite3_backup object.If sqlite3_backup_step() has not yet returned SQLITE_DONE, then anyactive write-transaction on the destination database is rolled back.The sqlite3_backup object is invalidand may not be used following a call to sqlite3_backup_finish().
The value returned by sqlite3_backup_finish is SQLITE_OK if nosqlite3_backup_step() errors occurred, regardless or whether or notsqlite3_backup_step() completed.If an out-of-memory condition or IO error occurred during any priorsqlite3_backup_step() call on the same sqlite3_backup object, thensqlite3_backup_finish() returns the corresponding error code.
A return of SQLITE_BUSY or SQLITE_LOCKED from sqlite3_backup_step()is not a permanent error and does not affect the return value ofsqlite3_backup_finish().
sqlite3_backup_remaining() and sqlite3_backup_pagecount()
Each call to sqlite3_backup_step() sets two values insidethe sqlite3_backup object: the number of pages still to be backedup and the total number of pages in the source database file.The sqlite3_backup_remaining() and sqlite3_backup_pagecount() interfacesretrieve these two values, respectively.
The values returned by these functions are only updated bysqlite3_backup_step(). If the source database is modified during a backupoperation, then the values are not updated to account for any extrapages that need to be updated or the size of the source database filechanging.
Concurrent Usage of Database Handles
The source database connection may be used by the application for otherpurposes while a backup operation is underway or being initialized.If SQLite is compiled and configured to support threadsafe databaseconnections, then the source database connection may be used concurrentlyfrom within other threads.
However, the application must guarantee that the destinationdatabase connection is not passed to any other API (by any thread) aftersqlite3_backup_init() is called and before the corresponding call tosqlite3_backup_finish(). SQLite does not currently check to seeif the application incorrectly accesses the destination database connectionand so no error code is reported, but the operations may malfunctionnevertheless. Use of the destination database connection while abackup is in progress might also also cause a mutex deadlock.
If running in shared cache mode, the application mustguarantee that the shared cache used by the destination databaseis not accessed while the backup is running. In practice this meansthat the application must guarantee that the disk file beingbacked up to is not accessed by any connection within the process,not just the specific connection that was passed to sqlite3_backup_init().
The sqlite3_backup object itself is partially threadsafe. Multiplethreads may safely make multiple concurrent calls to sqlite3_backup_step().However, the sqlite3_backup_remaining() and sqlite3_backup_pagecount()APIs are not strictly speaking threadsafe. If they are invoked at thesame time as another thread is invoking sqlite3_backup_step() it ispossible that they return invalid values.
Collation Needed Callbacksint sqlite3_collation_needed( sqlite3*, void*, void(*)(void*,sqlite3*,int eTextRep,const char*));int sqlite3_collation_needed16( sqlite3*, void*, void(*)(void*,sqlite3*,int eTextRep,const void*));
To avoid having to register all collation sequences before a databasecan be used, a single callback function may be registered with thedatabase connection to be invoked whenever an undefined collationsequence is required.
If the function is registered using the sqlite3_collation_needed() API,then it is passed the names of undefined collation sequences as stringsencoded in UTF-8. If sqlite3_collation_needed16() is used,the names are passed as UTF-16 in machine native byte order.A call to either function replaces the existing collation-needed callback.
When the callback is invoked, the first argument passed is a copyof the second argument to sqlite3_collation_needed() orsqlite3_collation_needed16(). The second argument is the databaseconnection. The third argument is one of SQLITE_UTF8, SQLITE_UTF16BE,or SQLITE_UTF16LE, indicating the most desirable form of the collationsequence function required. The fourth parameter is the name of therequired collation sequence.
The callback function should register the desired collation usingsqlite3_create_collation(), sqlite3_create_collation16(), orsqlite3_create_collation_v2().
Source Of Data In A Query Resultconst char *sqlite3_column_database_name(sqlite3_stmt*,int);const void *sqlite3_column_database_name16(sqlite3_stmt*,int);const char *sqlite3_column_table_name(sqlite3_stmt*,int);const void *sqlite3_column_table_name16(sqlite3_stmt*,int);const char *sqlite3_column_origin_name(sqlite3_stmt*,int);const void *sqlite3_column_origin_name16(sqlite3_stmt*,int);
These routines provide a means to determine the database, table, andtable column that is the origin of a particular result column inSELECT statement.The name of the database or table or column can be returned aseither a UTF-8 or UTF-16 string. The _database_ routines returnthe database name, the _table_ routines return the table name, andthe origin_ routines return the column name.The returned string is valid until the prepared statement is destroyedusing sqlite3_finalize() or until the statement is automaticallyreprepared by the first call to sqlite3_step() for a particular runor until the same information is requestedagain in a different encoding.
The names returned are the original un-aliased names of thedatabase, table, and column.
The first argument to these interfaces is a prepared statement.These functions return information about the Nth result column returned bythe statement, where N is the second function argument.The left-most column is column 0 for these routines.
If the Nth column returned by the statement is an expression orsubquery and is not a column value, then all of these functions returnNULL. These routine might also return NULL if a memory allocation erroroccurs. Otherwise, they return the name of the attached database, table,or column that query result column was extracted from.
As with all other SQLite APIs, those whose names end with "16" returnUTF-16 encoded strings and the other functions return UTF-8.
These APIs are only available if the library was compiled with theSQLITE_ENABLE_COLUMN_METADATA C-preprocessor symbol.
If two or more threads call one or more of these routines against the sameprepared statement and column at the same time then the results areundefined.
If two or more threads call one or morecolumn metadata interfacesfor the same prepared statement and result columnat the same time then the results are undefined.
Declared Datatype Of A Query Resultconst char *sqlite3_column_decltype(sqlite3_stmt*,int);const void *sqlite3_column_decltype16(sqlite3_stmt*,int);
The first parameter is a prepared statement.If this statement is a SELECT statement and the Nth column of thereturned result set of that SELECT is a table column (not anexpression or subquery) then the declared type of the tablecolumn is returned. If the Nth column of the result set is anexpression or subquery, then a NULL pointer is returned.The returned string is always UTF-8 encoded.
For example, given the database schema:
CREATE TABLE t1(c1 VARIANT);
and the following statement to be compiled:
SELECT c1 + 1, c1 FROM t1;
this routine would return the string "VARIANT" for the second resultcolumn (i==1), and a NULL pointer for the first result column (i==0).
SQLite uses dynamic run-time typing. So just because a columnis declared to contain a particular type does not mean that thedata stored in that column is of the declared type. SQLite isstrongly typed, but the typing is dynamic not static. Typeis associated with individual values, not with the containersused to hold those values.
Column Names In A Result Setconst char *sqlite3_column_name(sqlite3_stmt*, int N);const void *sqlite3_column_name16(sqlite3_stmt*, int N);
These routines return the name assigned to a particular columnin the result set of a SELECT statement. The sqlite3_column_name()interface returns a pointer to a zero-terminated UTF-8 stringand sqlite3_column_name16() returns a pointer to a zero-terminatedUTF-16 string. The first parameter is the prepared statementthat implements the SELECT statement. The second parameter is thecolumn number. The leftmost column is number 0.
The returned string pointer is valid until either the prepared statementis destroyed by sqlite3_finalize() or until the statement is automaticallyreprepared by the first call to sqlite3_step() for a particular runor until the next call tosqlite3_column_name() or sqlite3_column_name16() on the same column.
If sqlite3_malloc() fails during the processing of either routine(for example during a conversion from UTF-8 to UTF-16) then aNULL pointer is returned.
The name of a result column is the value of the "AS" clause forthat column, if there is an AS clause. If there is no AS clausethen the name of the column is unspecified and may change fromone release of SQLite to the next.
Commit And Rollback Notification Callbacksvoid *sqlite3_commit_hook(sqlite3*, int(*)(void*), void*);void *sqlite3_rollback_hook(sqlite3*, void(*)(void *), void*);
The sqlite3_commit_hook() interface registers a callbackfunction to be invoked whenever a transaction is committed.Any callback set by a previous call to sqlite3_commit_hook()for the same database connection is overridden.The sqlite3_rollback_hook() interface registers a callbackfunction to be invoked whenever a transaction is rolled back.Any callback set by a previous call to sqlite3_rollback_hook()for the same database connection is overridden.The pArg argument is passed through to the callback.If the callback on a commit hook function returns non-zero,then the commit is converted into a rollback.
The sqlite3_commit_hook(D,C,P) and sqlite3_rollback_hook(D,C,P) functionsreturn the P argument from the previous call of the same functionon the same database connection D, or NULL forthe first call for each function on D.
The commit and rollback hook callbacks are not reentrant.The callback implementation must not do anything that will modifythe database connection that invoked the callback. Any actionsto modify the database connection must be deferred until after thecompletion of the sqlite3_step() call that triggered the commitor rollback hook in the first place.Note that running any other SQL statements, including SELECT statements,or merely calling sqlite3_prepare_v2() and sqlite3_step() will modifythe database connections for the meaning of "modify" in this paragraph.
Registering a NULL function disables the callback.
When the commit hook callback routine returns zero, the COMMIToperation is allowed to continue normally. If the commit hookreturns non-zero, then the COMMIT is converted into a ROLLBACK.The rollback hook is invoked on a rollback that results from a commithook returning non-zero, just as it would be with any other rollback.
For the purposes of this API, a transaction is said to have beenrolled back if an explicit "ROLLBACK" statement is executed, oran error or constraint causes an implicit rollback to occur.The rollback callback is not invoked if a transaction isautomatically rolled back because the database connection is closed.
See also the sqlite3_update_hook() interface.
Run-Time Library Compilation Options Diagnostics#ifndef SQLITE_OMIT_COMPILEOPTION_DIAGSint sqlite3_compileoption_used(const char *zOptName);const char *sqlite3_compileoption_get(int N);#endif
The sqlite3_compileoption_used() function returns 0 or 1indicating whether the specified option was defined atcompile time. The SQLITE_ prefix may be omitted from theoption name passed to sqlite3_compileoption_used().
The sqlite3_compileoption_get() function allows iteratingover the list of options that were defined at compile time byreturning the N-th compile time option string. If N is out of range,sqlite3_compileoption_get() returns a NULL pointer. The SQLITE_prefix is omitted from any strings returned bysqlite3_compileoption_get().
Support for the diagnostic functions sqlite3_compileoption_used()and sqlite3_compileoption_get() may be omitted by specifying theSQLITE_OMIT_COMPILEOPTION_DIAGS option at compile time.
See also: SQL functions sqlite_compileoption_used() andsqlite_compileoption_get() and the compile_options pragma.
Determine If An SQL Statement Is Completeint sqlite3_complete(const char *sql);int sqlite3_complete16(const void *sql);
These routines are useful during command-line input to determine if thecurrently entered text seems to form a complete SQL statement orif additional input is needed before sending the text intoSQLite for parsing. These routines return 1 if the input stringappears to be a complete SQL statement. A statement is judged to becomplete if it ends with a semicolon token and is not a prefix of awell-formed CREATE TRIGGER statement. Semicolons that are embedded withinstring literals or quoted identifier names or comments are notindependent tokens (they are part of the token in which they areembedded) and thus do not count as a statement terminator. Whitespaceand comments that follow the final semicolon are ignored.
These routines return 0 if the statement is incomplete. If amemory allocation fails, then SQLITE_NOMEM is returned.
These routines do not parse the SQL statements thuswill not detect syntactically incorrect SQL.
If SQLite has not been initialized using sqlite3_initialize() priorto invoking sqlite3_complete16() then sqlite3_initialize() is invokedautomatically by sqlite3_complete16(). If that initialization fails,then the return value from sqlite3_complete16() will be non-zeroregardless of whether or not the input SQL is complete.
The input to sqlite3_complete() must be a zero-terminatedUTF-8 string.
The input to sqlite3_complete16() must be a zero-terminatedUTF-16 string in native byte order.
Define New Collating Sequencesint sqlite3_create_collation( sqlite3*, const char *zName, int eTextRep, void *pArg, int(*xCompare)(void*,int,const void*,int,const void*));int sqlite3_create_collation_v2( sqlite3*, const char *zName, int eTextRep, void *pArg, int(*xCompare)(void*,int,const void*,int,const void*), void(*xDestroy)(void*));int sqlite3_create_collation16( sqlite3*, const void *zName, int eTextRep, void *pArg, int(*xCompare)(void*,int,const void*,int,const void*));
These functions add, remove, or modify a collation associatedwith the database connection specified as the first argument.
The name of the collation is a UTF-8 stringfor sqlite3_create_collation() and sqlite3_create_collation_v2()and a UTF-16 string in native byte order for sqlite3_create_collation16().Collation names that compare equal according to sqlite3_strnicmp() areconsidered to be the same name.
The third argument (eTextRep) must be one of the constants:
SQLITE_UTF8, SQLITE_UTF16LE, SQLITE_UTF16BE, SQLITE_UTF16, or SQLITE_UTF16_ALIGNED.The eTextRep argument determines the encoding of strings passedto the collating function callback, xCallback.The SQLITE_UTF16 and SQLITE_UTF16_ALIGNED values for eTextRepforce strings to be UTF16 with native byte order.The SQLITE_UTF16_ALIGNED value for eTextRep forces strings to beginon an even byte address.
The fourth argument, pArg, is an application data pointer that is passedthrough as the first argument to the collating function callback.
The fifth argument, xCallback, is a pointer to the collating function.Multiple collating functions can be registered using the same name butwith different eTextRep parameters and SQLite will use whicheverfunction requires the least amount of data transformation.If the xCallback argument is NULL then the collating function isdeleted. When all collating functions having the same name are deleted,that collation is no longer usable.
The collating function callback is invoked with a copy of the pArgapplication data pointer and with two strings in the encoding specifiedby the eTextRep argument. The collating function must return aninteger that is negative, zero, or positiveif the first string is less than, equal to, or greater than the second,respectively. A collating function must always return the same answergiven the same inputs. If two or more collating functions are registeredto the same collation name (using different eTextRep values) then allmust give an equivalent answer when invoked with equivalent strings.The collating function must obey the following properties for allstrings A, B, and C:
If a collating function fails any of the above constraints and thatcollating function is registered and used, then the behavior of SQLiteis undefined.
The sqlite3_create_collation_v2() works like sqlite3_create_collation()with the addition that the xDestroy callback is invoked on pArg whenthe collating function is deleted.Collating functions are deleted when they are overridden by latercalls to the collation creation functions or when thedatabase connection is closed using sqlite3_close().
The xDestroy callback is not called if thesqlite3_create_collation_v2() function fails. Applications that invokesqlite3_create_collation_v2() with a non-NULL xDestroy argument shouldcheck the return code and dispose of the application data pointerthemselves rather than expecting SQLite to deal with it for them.This is different from every other SQLite interface. The inconsistencyis unfortunate but cannot be changed without breaking backwardscompatibility.
See also: sqlite3_collation_needed() and sqlite3_collation_needed16().
Register A Virtual Table Implementationint sqlite3_create_module( sqlite3 *db, /* SQLite connection to register module with */ const char *zName, /* Name of the module */ const sqlite3_module *p, /* Methods for the module */ void *pClientData /* Client data for xCreate/xConnect */);int sqlite3_create_module_v2( sqlite3 *db, /* SQLite connection to register module with */ const char *zName, /* Name of the module */ const sqlite3_module *p, /* Methods for the module */ void *pClientData, /* Client data for xCreate/xConnect */ void(*xDestroy)(void*) /* Module destructor function */);
These routines are used to register a new virtual table module name.Module names must be registered beforecreating a new virtual table using the module and before using apreexisting virtual table for the module.
The module name is registered on the database connection specifiedby the first parameter. The name of the module is given by thesecond parameter. The third parameter is a pointer tothe implementation of the virtual table module. The fourthparameter is an arbitrary client data pointer that is passed throughinto the xCreate and xConnect methods of the virtual table modulewhen a new virtual table is be being created or reinitialized.
The sqlite3_create_module_v2() interface has a fifth parameter whichis a pointer to a destructor for the pClientData. SQLite willinvoke the destructor function (if it is not NULL) when SQLiteno longer needs the pClientData pointer. The destructor will alsobe invoked if the call to sqlite3_create_module_v2() fails.The sqlite3_create_module()interface is equivalent to sqlite3_create_module_v2() with a NULLdestructor.
Error Codes And Messagesint sqlite3_errcode(sqlite3 *db);int sqlite3_extended_errcode(sqlite3 *db);const char *sqlite3_errmsg(sqlite3*);const void *sqlite3_errmsg16(sqlite3*);
The sqlite3_errcode() interface returns the numeric result code orextended result code for the most recent failed sqlite3_* API callassociated with a database connection. If a prior API call failedbut the most recent API call succeeded, the return value fromsqlite3_errcode() is undefined. The sqlite3_extended_errcode()interface is the same except that it always returns theextended result code even when extended result codes aredisabled.
The sqlite3_errmsg() and sqlite3_errmsg16() return English-languagetext that describes the error, as either UTF-8 or UTF-16 respectively.Memory to hold the error message string is managed internally.The application does not need to worry about freeing the result.However, the error string might be overwritten or deallocated bysubsequent calls to other SQLite interface functions.
When the serialized threading mode is in use, it might be thecase that a second error occurs on a separate thread in betweenthe time of the first error and the call to these interfaces.When that happens, the second error will be reported since theseinterfaces always report the most recent result. To avoidthis, each thread can obtain exclusive use of the database connection Dby invoking sqlite3_mutex_enter(sqlite3_db_mutex(D)) before beginningto use D and invoking sqlite3_mutex_leave(sqlite3_db_mutex(D)) afterall calls to the interfaces listed here are completed.
If an interface fails with SQLITE_MISUSE, that means the interfacewas invoked incorrectly by the application. In that case, theerror code and message may or may not be set.
Memory Allocation Subsystemvoid *sqlite3_malloc(int);void *sqlite3_realloc(void*, int);void sqlite3_free(void*);
The SQLite core uses these three routines for all of its owninternal memory allocation needs. "Core" in the previous sentencedoes not include operating-system specific VFS implementation. TheWindows VFS uses native malloc() and free() for some operations.
The sqlite3_malloc() routine returns a pointer to a blockof memory at least N bytes in length, where N is the parameter.If sqlite3_malloc() is unable to obtain sufficient freememory, it returns a NULL pointer. If the parameter N tosqlite3_malloc() is zero or negative then sqlite3_malloc() returnsa NULL pointer.
Calling sqlite3_free() with a pointer previously returnedby sqlite3_malloc() or sqlite3_realloc() releases that memory sothat it might be reused. The sqlite3_free() routine isa no-op if is called with a NULL pointer. Passing a NULL pointerto sqlite3_free() is harmless. After being freed, memoryshould neither be read nor written. Even reading previously freedmemory might result in a segmentation fault or other severe error.Memory corruption, a segmentation fault, or other severe errormight result if sqlite3_free() is called with a non-NULL pointer thatwas not obtained from sqlite3_malloc() or sqlite3_realloc().
The sqlite3_realloc() interface attempts to resize aprior memory allocation to be at least N bytes, where N is thesecond parameter. The memory allocation to be resized is the firstparameter. If the first parameter to sqlite3_realloc()is a NULL pointer then its behavior is identical to callingsqlite3_malloc(N) where N is the second parameter to sqlite3_realloc().If the second parameter to sqlite3_realloc() is zero ornegative then the behavior is exactly the same as callingsqlite3_free(P) where P is the first parameter to sqlite3_realloc().sqlite3_realloc() returns a pointer to a memory allocationof at least N bytes in size or NULL if sufficient memory is unavailable.If M is the size of the prior allocation, then min(N,M) bytesof the prior allocation are copied into the beginning of buffer returnedby sqlite3_realloc() and the prior allocation is freed.If sqlite3_realloc() returns NULL, then the prior allocationis not freed.
The memory returned by sqlite3_malloc() and sqlite3_realloc()is always aligned to at least an 8 byte boundary, or to a4 byte boundary if the SQLITE_4_BYTE_ALIGNED_MALLOC compile-timeoption is used.
In SQLite version 3.5.0 and 3.5.1, it was possible to definethe SQLITE_OMIT_MEMORY_ALLOCATION which would cause the built-inimplementation of these routines to be omitted. That capabilityis no longer provided. Only built-in memory allocators can be used.
The Windows OS interface layer callsthe system malloc() and free() directly when convertingfilenames between the UTF-8 encoding used by SQLiteand whatever filename encoding is used by the particular Windowsinstallation. Memory allocation errors are detected, butthey are reported back as SQLITE_CANTOPEN orSQLITE_IOERR rather than SQLITE_NOMEM.
The pointer arguments to sqlite3_free() and sqlite3_realloc()must be either NULL or else pointers obtained from a priorinvocation of sqlite3_malloc() or sqlite3_realloc() that havenot yet been released.
The application must not read or write any part ofa block of memory after it has been released usingsqlite3_free() or sqlite3_realloc().
Convenience Routines For Running Queriesint sqlite3_get_table( sqlite3 *db, /* An open database */ const char *zSql, /* SQL to be evaluated */ char ***pazResult, /* Results of the query */ int *pnRow, /* Number of result rows written here */ int *pnColumn, /* Number of result columns written here */ char **pzErrmsg /* Error msg written here */);void sqlite3_free_table(char **result);
This is a legacy interface that is preserved for backwards compatibility.Use of this interface is not recommended.
Definition: A result table is memory data structure created by thesqlite3_get_table() interface. A result table records thecomplete query results from one or more queries.
The table conceptually has a number of rows and columns. Butthese numbers are not part of the result table itself. Thesenumbers are obtained separately. Let N be the number of rowsand M be the number of columns.
A result table is an array of pointers to zero-terminated UTF-8 strings.There are (N+1)*M elements in the array. The first M pointers pointto zero-terminated strings that contain the names of the columns.The remaining entries all point to query results. NULL values resultin NULL pointers. All other values are in their UTF-8 zero-terminatedstring representation as returned by sqlite3_column_text().
A result table might consist of one or more memory allocations.It is not safe to pass a result table directly to sqlite3_free().A result table should be deallocated using sqlite3_free_table().
As an example of the result table format, suppose a query resultis as follows:
Name | Age-----------------------Alice | 43Bob | 28Cindy | 21
There are two column (M==2) and three rows (N==3). Thus theresult table has 8 entries. Suppose the result table is storedin an array names azResult. Then azResult holds this content:
azResult[0] = "Name";azResult[1] = "Age";azResult[2] = "Alice";azResult[3] = "43";azResult[4] = "Bob";azResult[5] = "28";azResult[6] = "Cindy";azResult[7] = "21";
The sqlite3_get_table() function evaluates one or moresemicolon-separated SQL statements in the zero-terminated UTF-8string of its 2nd parameter and returns a result table to thepointer given in its 3rd parameter.
After the application has finished with the result from sqlite3_get_table(),it must pass the result table pointer to sqlite3_free_table() in order torelease the memory that was malloced. Because of the way thesqlite3_malloc() happens within sqlite3_get_table(), the callingfunction must not try to call sqlite3_free() directly. Onlysqlite3_free_table() is able to release the memory properly and safely.
The sqlite3_get_table() interface is implemented as a wrapper aroundsqlite3_exec(). The sqlite3_get_table() routine does not have accessto any internal data structures of SQLite. It uses only the publicinterface defined here. As a consequence, errors that occur in thewrapper layer outside of the internal sqlite3_exec() call are notreflected in subsequent calls to sqlite3_errcode() orsqlite3_errmsg().
Function Auxiliary Datavoid *sqlite3_get_auxdata(sqlite3_context*, int N);void sqlite3_set_auxdata(sqlite3_context*, int N, void*, void (*)(void*));
The following two functions may be used by scalar SQL functions toassociate metadata with argument values. If the same value is passed tomultiple invocations of the same SQL function during query execution, undersome circumstances the associated metadata may be preserved. This maybe used, for example, to add a regular-expression matching scalarfunction. The compiled version of the regular expression is stored asmetadata associated with the SQL value passed as the regular expressionpattern. The compiled regular expression can be reused on multipleinvocations of the same function so that the original pattern stringdoes not need to be recompiled on each invocation.
The sqlite3_get_auxdata() interface returns a pointer to the metadataassociated by the sqlite3_set_auxdata() function with the Nth argumentvalue to the application-defined function. If no metadata has been everbeen set for the Nth argument of the function, or if the correspondingfunction parameter has changed since the meta-data was set,then sqlite3_get_auxdata() returns a NULL pointer.
The sqlite3_set_auxdata() interface saves the metadatapointed to by its 3rd parameter as the metadata for the N-thargument of the application-defined function. Subsequentcalls to sqlite3_get_auxdata() might return this data, if it hasnot been destroyed.If it is not NULL, SQLite will invoke the destructorfunction given by the 4th parameter to sqlite3_set_auxdata() onthe metadata when the corresponding function parameter changesor when the SQL statement completes, whichever comes first.
SQLite is free to call the destructor and drop metadata on anyparameter of any function at any time. The only guarantee is thatthe destructor will be called before the metadata is dropped.
In practice, metadata is preserved between function calls forexpressions that are constant at compile time. This includes literalvalues and parameters.
These routines must be called from the same thread in whichthe SQL function is running.
Initialize The SQLite Libraryint sqlite3_initialize(void);int sqlite3_shutdown(void);int sqlite3_os_init(void);int sqlite3_os_end(void);
The sqlite3_initialize() routine initializes theSQLite library. The sqlite3_shutdown() routinedeallocates any resources that were allocated by sqlite3_initialize().These routines are designed to aid in process initialization andshutdown on embedded systems. Workstation applications usingSQLite normally do not need to invoke either of these routines.
A call to sqlite3_initialize() is an "effective" call if it isthe first time sqlite3_initialize() is invoked during the lifetime ofthe process, or if it is the first time sqlite3_initialize() is invokedfollowing a call to sqlite3_shutdown(). Only an effective callof sqlite3_initialize() does any initialization. All other callsare harmless no-ops.
A call to sqlite3_shutdown() is an "effective" call if it is the firstcall to sqlite3_shutdown() since the last sqlite3_initialize(). Onlyan effective call to sqlite3_shutdown() does any deinitialization.All other valid calls to sqlite3_shutdown() are harmless no-ops.
The sqlite3_initialize() interface is threadsafe, but sqlite3_shutdown()is not. The sqlite3_shutdown() interface must only be called from asingle thread. All open database connections must be closed and allother SQLite resources must be deallocated prior to invokingsqlite3_shutdown().
Among other things, sqlite3_initialize() will invokesqlite3_os_init(). Similarly, sqlite3_shutdown()will invoke sqlite3_os_end().
The sqlite3_initialize() routine returns SQLITE_OK on success.If for some reason, sqlite3_initialize() is unable to initializethe library (perhaps it is unable to allocate a needed resource suchas a mutex) it returns an error code other than SQLITE_OK.
The sqlite3_initialize() routine is called internally by many otherSQLite interfaces so that an application usually does not need toinvoke sqlite3_initialize() directly. For example, sqlite3_open()calls sqlite3_initialize() so the SQLite library will be automaticallyinitialized when sqlite3_open() is called if it has not be initializedalready. However, if SQLite is compiled with the SQLITE_OMIT_AUTOINITcompile-time option, then the automatic calls to sqlite3_initialize()are omitted and the application must call sqlite3_initialize() directlyprior to using any other SQLite interface. For maximum portability,it is recommended that applications always invoke sqlite3_initialize()directly prior to using any other SQLite interface. Future releasesof SQLite may require this. In other words, the behavior exhibitedwhen SQLite is compiled with SQLITE_OMIT_AUTOINIT might become thedefault behavior in some future release of SQLite.
The sqlite3_os_init() routine does operating-system specificinitialization of the SQLite library. The sqlite3_os_end()routine undoes the effect of sqlite3_os_init(). Typical tasksperformed by these routines include allocation or deallocationof static resources, initialization of global variables,setting up a default sqlite3_vfs module, or setting upa default configuration using sqlite3_config().
The application should never invoke either sqlite3_os_init()or sqlite3_os_end() directly. The application should only invokesqlite3_initialize() and sqlite3_shutdown(). The sqlite3_os_init()interface is called automatically by sqlite3_initialize() andsqlite3_os_end() is called by sqlite3_shutdown(). Appropriateimplementations for sqlite3_os_init() and sqlite3_os_end()are built into SQLite when it is compiled for Unix, Windows, or OS/2.When built for other platforms(using the SQLITE_OS_OTHER=1 compile-timeoption) the application must supply a suitable implementation forsqlite3_os_init() and sqlite3_os_end(). An application-suppliedimplementation of sqlite3_os_init() or sqlite3_os_end()must return SQLITE_OK on success and some other error code uponfailure.
Run-Time Library Version NumbersSQLITE_EXTERN const char sqlite3_version[];const char *sqlite3_libversion(void);const char *sqlite3_sourceid(void);int sqlite3_libversion_number(void);
These interfaces provide the same information as the SQLITE_VERSION,SQLITE_VERSION_NUMBER, and SQLITE_SOURCE_ID C preprocessor macrosbut are associated with the library instead of the header file. Cautiousprogrammers might include assert() statements in their application toverify that values returned by these interfaces match the macros inthe header, and thus insure that the application iscompiled with matching library and header files.
assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );assert( strcmp(sqlite3_sourceid(),SQLITE_SOURCE_ID)==0 );assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );
The sqlite3_version[] string constant contains the text of SQLITE_VERSIONmacro. The sqlite3_libversion() function returns a pointer to theto the sqlite3_version[] string constant. The sqlite3_libversion()function is provided for use in DLLs since DLL users usually do not havedirect access to string constants within the DLL. Thesqlite3_libversion_number() function returns an integer equal toSQLITE_VERSION_NUMBER. The sqlite3_sourceid() function returnsa pointer to a string constant whose value is the same as theSQLITE_SOURCE_ID C preprocessor macro.
See also: sqlite_version() and sqlite_source_id().
Memory Allocator Statisticssqlite3_int64 sqlite3_memory_used(void);sqlite3_int64 sqlite3_memory_highwater(int resetFlag);
SQLite provides these two interfaces for reporting on the statusof the sqlite3_malloc(), sqlite3_free(), and sqlite3_realloc()routines, which form the built-in memory allocation subsystem.
The sqlite3_memory_used() routine returns the number of bytesof memory currently outstanding (malloced but not freed).The sqlite3_memory_highwater() routine returns the maximumvalue of sqlite3_memory_used() since the high-water markwas last reset. The values returned by sqlite3_memory_used() andsqlite3_memory_highwater() include any overheadadded by SQLite in its implementation of sqlite3_malloc(),but not overhead added by the any underlying system libraryroutines that sqlite3_malloc() may call.
The memory high-water mark is reset to the current value ofsqlite3_memory_used() if and only if the parameter tosqlite3_memory_highwater() is true. The value returnedby sqlite3_memory_highwater(1) is the high-water markprior to the reset.
Formatted String Printing Functionschar *sqlite3_mprintf(const char*,...);char *sqlite3_vmprintf(const char*, va_list);char *sqlite3_snprintf(int,char*,const char*, ...);char *sqlite3_vsnprintf(int,char*,const char*, va_list);
These routines are work-alikes of the "printf()" family of functionsfrom the standard C library.
The sqlite3_mprintf() and sqlite3_vmprintf() routines write theirresults into memory obtained from sqlite3_malloc().The strings returned by these two routines should bereleased by sqlite3_free(). Both routines return aNULL pointer if sqlite3_malloc() is unable to allocate enoughmemory to hold the resulting string.
The sqlite3_snprintf() routine is similar to "snprintf()" fromthe standard C library. The result is written into thebuffer supplied as the second parameter whose size is given bythe first parameter. Note that the order of thefirst two parameters is reversed from snprintf(). This is anhistorical accident that cannot be fixed without breakingbackwards compatibility. Note also that sqlite3_snprintf()returns a pointer to its buffer instead of the number ofcharacters actually written into the buffer. We admit thatthe number of characters written would be a more useful returnvalue but we cannot change the implementation of sqlite3_snprintf()now without breaking compatibility.
As long as the buffer size is greater than zero, sqlite3_snprintf()guarantees that the buffer is always zero-terminated. The firstparameter "n" is the total size of the buffer, including space forthe zero terminator. So the longest string that can be completelywritten will be n-1 characters.
The sqlite3_vsnprintf() routine is a varargs version of sqlite3_snprintf().
These routines all implement some additional formattingoptions that are useful for constructing SQL statements.All of the usual printf() formatting options apply. In addition, thereis are "%q", "%Q", and "%z" options.
The %q option works like %s in that it substitutes a nul-terminatedstring from the argument list. But %q also doubles every '\'' character.%q is designed for use inside a string literal. By doubling each '\''character it escapes that character and allows it to be inserted intothe string.
For example, assume the string variable zText contains text as follows:
char *zText = "It's a happy day!";
One can use this text in an SQL statement as follows:
char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES('%q')", zText);sqlite3_exec(db, zSQL, 0, 0, 0);sqlite3_free(zSQL);Because the %q format string is used, the '\'' character in zTextis escaped and the SQL generated is as follows:
INSERT INTO table1 VALUES('It''s a happy day!')This is correct. Had we used %s instead of %q, the generated SQLwould have looked like this:
INSERT INTO table1 VALUES('It's a happy day!');This second example is an SQL syntax error. As a general rule you shouldalways use %q instead of %s when inserting text into a string literal.
The %Q option works like %q except it also adds single quotes aroundthe outside of the total string. Additionally, if the parameter in theargument list is a NULL pointer, %Q substitutes the text "NULL" (withoutsingle quotes). So, for example, one could say:
char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES(%Q)", zText);sqlite3_exec(db, zSQL, 0, 0, 0);sqlite3_free(zSQL);The code above will render a correct SQL statement in the zSQLvariable even if the zText variable is a NULL pointer.
The "%z" formatting option works like "%s" but with theaddition that after the string has been read and copied intothe result, sqlite3_free() is called on the input string.
Mutexessqlite3_mutex *sqlite3_mutex_alloc(int);void sqlite3_mutex_free(sqlite3_mutex*);void sqlite3_mutex_enter(sqlite3_mutex*);int sqlite3_mutex_try(sqlite3_mutex*);void sqlite3_mutex_leave(sqlite3_mutex*);
The SQLite core uses these routines for threadsynchronization. Though they are intended for internaluse by SQLite, code that links against SQLite ispermitted to use any of these routines.
The SQLite source code contains multiple implementationsof these mutex routines. An appropriate implementationis selected automatically at compile-time. The followingimplementations are available in the SQLite core:
SQLITE_MUTEX_OS2 SQLITE_MUTEX_PTHREADS SQLITE_MUTEX_W32 SQLITE_MUTEX_NOOPThe SQLITE_MUTEX_NOOP implementation is a set of routinesthat does no real locking and is appropriate for use ina single-threaded application. The SQLITE_MUTEX_OS2,SQLITE_MUTEX_PTHREADS, and SQLITE_MUTEX_W32 implementationsare appropriate for use on OS/2, Unix, and Windows.
If SQLite is compiled with the SQLITE_MUTEX_APPDEF preprocessormacro defined (with "-DSQLITE_MUTEX_APPDEF=1"), then no muteximplementation is included with the library. In this case theapplication must supply a custom mutex implementation using theSQLITE_CONFIG_MUTEX option of the sqlite3_config() functionbefore calling sqlite3_initialize() or any other public sqlite3_function that calls sqlite3_initialize().
The sqlite3_mutex_alloc() routine allocates a newmutex and returns a pointer to it. If it returns NULLthat means that a mutex could not be allocated. SQLitewill unwind its stack and return an error. The argumentto sqlite3_mutex_alloc() is one of these integer constants:
SQLITE_MUTEX_FAST SQLITE_MUTEX_RECURSIVE SQLITE_MUTEX_STATIC_MASTER SQLITE_MUTEX_STATIC_MEM SQLITE_MUTEX_STATIC_MEM2 SQLITE_MUTEX_STATIC_PRNG SQLITE_MUTEX_STATIC_LRU SQLITE_MUTEX_STATIC_LRU2The first two constants (SQLITE_MUTEX_FAST and SQLITE_MUTEX_RECURSIVE)cause sqlite3_mutex_alloc() to createa new mutex. The new mutex is recursive when SQLITE_MUTEX_RECURSIVEis used but not necessarily so when SQLITE_MUTEX_FAST is used.The mutex implementation does not need to make a distinctionbetween SQLITE_MUTEX_RECURSIVE and SQLITE_MUTEX_FAST if it doesnot want to. SQLite will only request a recursive mutex incases where it really needs one. If a faster non-recursive muteximplementation is available on the host platform, the mutex subsystemmight return such a mutex in response to SQLITE_MUTEX_FAST.
The other allowed parameters to sqlite3_mutex_alloc() (anything otherthan SQLITE_MUTEX_FAST and SQLITE_MUTEX_RECURSIVE) each returna pointer to a static preexisting mutex. Six static mutexes areused by the current version of SQLite. Future versions of SQLitemay add additional static mutexes. Static mutexes are for internaluse by SQLite only. Applications that use SQLite mutexes shoulduse only the dynamic mutexes returned by SQLITE_MUTEX_FAST orSQLITE_MUTEX_RECURSIVE.
Note that if one of the dynamic mutex parameters (SQLITE_MUTEX_FASTor SQLITE_MUTEX_RECURSIVE) is used then sqlite3_mutex_alloc()returns a different mutex on every call. But for the staticmutex types, the same mutex is returned on every call that hasthe same type number.
The sqlite3_mutex_free() routine deallocates a previouslyallocated dynamic mutex. SQLite is careful to deallocate everydynamic mutex that it allocates. The dynamic mutexes must not be inuse when they are deallocated. Attempting to deallocate a staticmutex results in undefined behavior. SQLite never deallocatesa static mutex.
The sqlite3_mutex_enter() and sqlite3_mutex_try() routines attemptto enter a mutex. If another thread is already within the mutex,sqlite3_mutex_enter() will block and sqlite3_mutex_try() will returnSQLITE_BUSY. The sqlite3_mutex_try() interface returns SQLITE_OKupon successful entry. Mutexes created usingSQLITE_MUTEX_RECURSIVE can be entered multiple times by the same thread.In such cases the,mutex must be exited an equal number of times before another threadcan enter. If the same thread tries to enter any otherkind of mutex more than once, the behavior is undefined.SQLite will never exhibitsuch behavior in its own use of mutexes.
Some systems (for example, Windows 95) do not support the operationimplemented by sqlite3_mutex_try(). On those systems, sqlite3_mutex_try()will always return SQLITE_BUSY. The SQLite core only ever usessqlite3_mutex_try() as an optimization so this is acceptable behavior.
The sqlite3_mutex_leave() routine exits a mutex that waspreviously entered by the same thread. The behavioris undefined if the mutex is not currently entered by thecalling thread or is not currently allocated. SQLite willnever do either.
If the argument to sqlite3_mutex_enter(), sqlite3_mutex_try(), orsqlite3_mutex_leave() is a NULL pointer, then all three routinesbehave as no-ops.
See also: sqlite3_mutex_held() and sqlite3_mutex_notheld().
Mutex Verification Routines#ifndef NDEBUGint sqlite3_mutex_held(sqlite3_mutex*);int sqlite3_mutex_notheld(sqlite3_mutex*);#endif
The sqlite3_mutex_held() and sqlite3_mutex_notheld() routinesare intended for use inside assert() statements. The SQLite corenever uses these routines except inside an assert() and applicationsare advised to follow the lead of the core. The SQLite core onlyprovides implementations for these routines when it is compiledwith the SQLITE_DEBUG flag. External mutex implementationsare only required to provide these routines if SQLITE_DEBUG isdefined and if NDEBUG is not defined.
These routines should return true if the mutex in their argumentis held or not held, respectively, by the calling thread.
The implementation is not required to provide versions of theseroutines that actually work. If the implementation does not provide workingversions of these routines, it should at least provide stubs that alwaysreturn true so that one does not get spurious assertion failures.
If the argument to sqlite3_mutex_held() is a NULL pointer thenthe routine should return 1. This seems counter-intuitive sinceclearly the mutex cannot be held if it does not exist. Butthe reason the mutex does not exist is because the build is notusing mutexes. And we do not want the assert() containing thecall to sqlite3_mutex_held() to fail, so a non-zero return isthe appropriate thing to do. The sqlite3_mutex_notheld()interface should also return 1 when given a NULL pointer.
Opening A New Database Connectionint sqlite3_open( const char *filename, /* Database filename (UTF-8) */ sqlite3 **ppDb /* OUT: SQLite db handle */);int sqlite3_open16( const void *filename, /* Database filename (UTF-16) */ sqlite3 **ppDb /* OUT: SQLite db handle */);int sqlite3_open_v2( const char *filename, /* Database filename (UTF-8) */ sqlite3 **ppDb, /* OUT: SQLite db handle */ int flags, /* Flags */ const char *zVfs /* Name of VFS module to use */);
These routines open an SQLite database file as specified by thefilename argument. The filename argument is interpreted as UTF-8 forsqlite3_open() and sqlite3_open_v2() and as UTF-16 in the native byteorder for sqlite3_open16(). A database connection handle is usuallyreturned in *ppDb, even if an error occurs. The only exception is thatif SQLite is unable to allocate memory to hold the sqlite3 object,a NULL will be written into *ppDb instead of a pointer to the sqlite3object. If the database is opened (and/or created) successfully, thenSQLITE_OK is returned. Otherwise an error code is returned. Thesqlite3_errmsg() or sqlite3_errmsg16() routines can be used to obtainan English language description of the error following a failure of anyof the sqlite3_open() routines.
The default encoding for the database will be UTF-8 ifsqlite3_open() or sqlite3_open_v2() is called andUTF-16 in the native byte order if sqlite3_open16() is used.
Whether or not an error occurs when it is opened, resourcesassociated with the database connection handle should be released bypassing it to sqlite3_close() when it is no longer required.
The sqlite3_open_v2() interface works like sqlite3_open()except that it accepts two additional parameters for additional controlover the new database connection. The flags parameter tosqlite3_open_v2() can take one ofthe following three values, optionally combined with theSQLITE_OPEN_NOMUTEX, SQLITE_OPEN_FULLMUTEX, SQLITE_OPEN_SHAREDCACHE,SQLITE_OPEN_PRIVATECACHE, and/or SQLITE_OPEN_URI flags:
SQLITE_OPEN_READONLYThe database is opened in read-only mode. If the database does notalready exist, an error is returned.SQLITE_OPEN_READWRITEThe database is opened for reading and writing if possible, or readingonly if the file is write protected by the operating system. In eithercase the database must already exist, otherwise an error is returned.SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATEThe database is opened for reading and writing, and is created ifit does not already exist. This is the behavior that is always used forsqlite3_open() and sqlite3_open16().If the 3rd parameter to sqlite3_open_v2() is not one of thecombinations shown above optionally combined with otherSQLITE_OPEN_* bitsthen the behavior is undefined.
If the SQLITE_OPEN_NOMUTEX flag is set, then the database connectionopens in the multi-thread threading mode as long as the single-threadmode has not been set at compile-time or start-time. If theSQLITE_OPEN_FULLMUTEX flag is set then the database connection opensin the serialized threading mode unless single-thread waspreviously selected at compile-time or start-time.The SQLITE_OPEN_SHAREDCACHE flag causes the database connection to beeligible to use shared cache mode, regardless of whether or not sharedcache is enabled using sqlite3_enable_shared_cache(). TheSQLITE_OPEN_PRIVATECACHE flag causes the database connection to notparticipate in shared cache mode even if it is enabled.
The fourth parameter to sqlite3_open_v2() is the name of thesqlite3_vfs object that defines the operating system interface thatthe new database connection should use. If the fourth parameter isa NULL pointer then the default sqlite3_vfs object is used.
If the filename is ":memory:", then a private, temporary in-memory databaseis created for the connection. This in-memory database will vanish whenthe database connection is closed. Future versions of SQLite mightmake use of additional special filenames that begin with the ":" character.It is recommended that when a database filename actually does begin witha ":" character you should prefix the filename with a pathname such as"./" to avoid ambiguity.
If the filename is an empty string, then a private, temporaryon-disk database will be created. This private database will beautomatically deleted as soon as the database connection is closed.
URI Filenames
If URI filename interpretation is enabled, and the filename argumentbegins with "file:", then the filename is interpreted as a URI. URIfilename interpretation is enabled if the SQLITE_OPEN_URI flag isset in the fourth argument to sqlite3_open_v2(), or if it hasbeen enabled globally using the SQLITE_CONFIG_URI option with thesqlite3_config() method or by the SQLITE_USE_URI compile-time option.As of SQLite version 3.7.7, URI filename interpretation is turned offby default, but future releases of SQLite might enable URI filenameinterpretation by default. See "URI filenames" for additionalinformation.
URI filenames are parsed according to RFC 3986. If the URI contains anauthority, then it must be either an empty string or the string"localhost". If the authority is not an empty string or "localhost", anerror is returned to the caller. The fragment component of a URI, ifpresent, is ignored.
SQLite uses the path component of the URI as the name of the disk filewhich contains the database. If the path begins with a '/' character,then it is interpreted as an absolute path. If the path does not beginwith a '/' (meaning that the authority section is omitted from the URI)then the path is interpreted as a relative path.On windows, the first component of an absolute pathis a drive specification (e.g. "C:").
The query component of a URI may contain parameters that are interpretedeither by SQLite itself, or by a custom VFS implementation.SQLite interprets the following three query parameters:
vfs: The "vfs" parameter may be used to specify the name ofa VFS object that provides the operating system interface that shouldbe used to access the database file on disk. If this option is set toan empty string the default VFS object is used. Specifying an unknownVFS is an error. If sqlite3_open_v2() is used and the vfs option ispresent, then the VFS specified by the option takes precedence overthe value passed as the fourth parameter to sqlite3_open_v2(). mode: The mode parameter may be set to either "ro", "rw" or"rwc". Attempting to set it to any other value is an error.If "ro" is specified, then the database is opened for read-onlyaccess, just as if the SQLITE_OPEN_READONLY flag had been set in thethird argument to sqlite3_prepare_v2(). If the mode option is set to"rw", then the database is opened for read-write (but not create)access, as if SQLITE_OPEN_READWRITE (but not SQLITE_OPEN_CREATE) hadbeen set. Value "rwc" is equivalent to setting bothSQLITE_OPEN_READWRITE and SQLITE_OPEN_CREATE. If sqlite3_open_v2() isused, it is an error to specify a value for the mode parameter that isless restrictive than that specified by the flags passed as the thirdparameter. cache: The cache parameter may be set to either "shared" or"private". Setting it to "shared" is equivalent to setting theSQLITE_OPEN_SHAREDCACHE bit in the flags argument passed tosqlite3_open_v2(). Setting the cache parameter to "private" isequivalent to setting the SQLITE_OPEN_PRIVATECACHE bit.If sqlite3_open_v2() is used and the "cache" parameter is present ina URI filename, its value overrides any behaviour requested by settingSQLITE_OPEN_PRIVATECACHE or SQLITE_OPEN_SHAREDCACHE flag.Specifying an unknown parameter in the query component of a URI is not anerror. Future versions of SQLite might understand additional queryparameters. See "query parameters with special meaning to SQLite" foradditional information.
URI filename examples URI filenames Results file:data.db Open the file "data.db" in the current directory. file:/home/fred/data.db
URI hexadecimal escape sequences (%HH) are supported within the path andquery components of a URI. A hexadecimal escape sequence consists of apercent sign - "%" - followed by exactly two hexadecimal digitsspecifying an octet value. Before the path or query components of aURI filename are interpreted, they are encoded using UTF-8 and allhexadecimal escape sequences replaced by a single byte containing thecorresponding octet. If this process generates an invalid UTF-8 encoding,the results are undefined.
Note to Windows users: The encoding used for the filename argumentof sqlite3_open() and sqlite3_open_v2() must be UTF-8, not whatevercodepage is currently defined. Filenames containing internationalcharacters must be converted to UTF-8 prior to passing them intosqlite3_open() or sqlite3_open_v2().
Tracing And Profiling Functionsvoid *sqlite3_trace(sqlite3*, void(*xTrace)(void*,const char*), void*);void *sqlite3_profile(sqlite3*, void(*xProfile)(void*,const char*,sqlite3_uint64), void*);
These routines register callback functions that can be used fortracing and profiling the execution of SQL statements.
The callback function registered by sqlite3_trace() is invoked atvarious times when an SQL statement is being run by sqlite3_step().The sqlite3_trace() callback is invoked with a UTF-8 rendering of theSQL statement text as the statement first begins executing.Additional sqlite3_trace() callbacks might occuras each triggered subprogram is entered. The callbacks for triggerscontain a UTF-8 SQL comment that identifies the trigger.
The callback function registered by sqlite3_profile() is invokedas each SQL statement finishes. The profile callback containsthe original statement text and an estimate of wall-clock timeof how long that statement took to run. The profile callbacktime is in units of nanoseconds, however the current implementationis only capable of millisecond resolution so the six least significantdigits in the time are meaningless. Future versions of SQLitemight provide greater resolution on the profiler callback. Thesqlite3_profile() function is considered experimental and issubject to change in future versions of SQLite.
Setting The Result Of An SQL Functionvoid sqlite3_result_blob(sqlite3_context*, const void*, int, void(*)(void*));void sqlite3_result_double(sqlite3_context*, double);void sqlite3_result_error(sqlite3_context*, const char*, int);void sqlite3_result_error16(sqlite3_context*, const void*, int);void sqlite3_result_error_toobig(sqlite3_context*);void sqlite3_result_error_nomem(sqlite3_context*);void sqlite3_result_error_code(sqlite3_context*, int);void sqlite3_result_int(sqlite3_context*, int);void sqlite3_result_int64(sqlite3_context*, sqlite3_int64);void sqlite3_result_null(sqlite3_context*);void sqlite3_result_text(sqlite3_context*, const char*, int, void(*)(void*));void sqlite3_result_text16(sqlite3_context*, const void*, int, void(*)(void*));void sqlite3_result_text16le(sqlite3_context*, const void*, int,void(*)(void*));void sqlite3_result_text16be(sqlite3_context*, const void*, int,void(*)(void*));void sqlite3_result_value(sqlite3_context*, sqlite3_value*);void sqlite3_result_zeroblob(sqlite3_context*, int n);
These routines are used by the xFunc or xFinal callbacks thatimplement SQL functions and aggregates. Seesqlite3_create_function() and sqlite3_create_function16()for additional information.
These functions work very much like the parameter binding family offunctions used to bind values to host parameters in prepared statements.Refer to the SQL parameter documentation for additional information.
The sqlite3_result_blob() interface sets the result froman application-defined function to be the BLOB whose content is pointedto by the second parameter and which is N bytes long where N is thethird parameter.
The sqlite3_result_zeroblob() interfaces set the result ofthe application-defined function to be a BLOB containing all zerobytes and N bytes in size, where N is the value of the 2nd parameter.
The sqlite3_result_double() interface sets the result froman application-defined function to be a floating point value specifiedby its 2nd argument.
The sqlite3_result_error() and sqlite3_result_error16() functionscause the implemented SQL function to throw an exception.SQLite uses the string pointed to by the2nd parameter of sqlite3_result_error() or sqlite3_result_error16()as the text of an error message. SQLite interprets the errormessage string from sqlite3_result_error() as UTF-8. SQLiteinterprets the string from sqlite3_result_error16() as UTF-16 in nativebyte order. If the third parameter to sqlite3_result_error()or sqlite3_result_error16() is negative then SQLite takes as the errormessage all text up through the first zero character.If the third parameter to sqlite3_result_error() orsqlite3_result_error16() is non-negative then SQLite takes that manybytes (not characters) from the 2nd parameter as the error message.The sqlite3_result_error() and sqlite3_result_error16()routines make a private copy of the error message text beforethey return. Hence, the calling function can deallocate ormodify the text after they return without harm.The sqlite3_result_error_code() function changes the error codereturned by SQLite as a result of an error in a function. By default,the error code is SQLITE_ERROR. A subsequent call to sqlite3_result_error()or sqlite3_result_error16() resets the error code to SQLITE_ERROR.
The sqlite3_result_toobig() interface causes SQLite to throw an errorindicating that a string or BLOB is too long to represent.
The sqlite3_result_nomem() interface causes SQLite to throw an errorindicating that a memory allocation failed.
The sqlite3_result_int() interface sets the return valueof the application-defined function to be the 32-bit signed integervalue given in the 2nd argument.The sqlite3_result_int64() interface sets the return valueof the application-defined function to be the 64-bit signed integervalue given in the 2nd argument.
The sqlite3_result_null() interface sets the return valueof the application-defined function to be NULL.
The sqlite3_result_text(), sqlite3_result_text16(),sqlite3_result_text16le(), and sqlite3_result_text16be() interfacesset the return value of the application-defined function to bea text string which is represented as UTF-8, UTF-16 native byte order,UTF-16 little endian, or UTF-16 big endian, respectively.SQLite takes the text result from the application fromthe 2nd parameter of the sqlite3_result_text* interfaces.If the 3rd parameter to the sqlite3_result_text* interfacesis negative, then SQLite takes result text from the 2nd parameterthrough the first zero character.If the 3rd parameter to the sqlite3_result_text* interfacesis non-negative, then as many bytes (not characters) of the textpointed to by the 2nd parameter are taken as the application-definedfunction result. If the 3rd parameter is non-negative, then itmust be the byte offset into the string where the NUL terminator wouldappear if the string where NUL terminated. If any NUL characters occurin the string at a byte offset that is less than the value of the 3rdparameter, then the resulting string will contain embedded NULs and theresult of expressions operating on strings with embedded NULs is undefined.If the 4th parameter to the sqlite3_result_text* interfacesor sqlite3_result_blob is a non-NULL pointer, then SQLite calls thatfunction as the destructor on the text or BLOB result when it hasfinished using that result.If the 4th parameter to the sqlite3_result_text* interfaces or tosqlite3_result_blob is the special constant SQLITE_STATIC, then SQLiteassumes that the text or BLOB result is in constant space and does notcopy the content of the parameter nor call a destructor on the contentwhen it has finished using that result.If the 4th parameter to the sqlite3_result_text* interfacesor sqlite3_result_blob is the special constant SQLITE_TRANSIENTthen SQLite makes a copy of the result into space obtained fromfrom sqlite3_malloc() before it returns.
The sqlite3_result_value() interface sets the result ofthe application-defined function to be a copy theunprotected sqlite3_value object specified by the 2nd parameter. Thesqlite3_result_value() interface makes a copy of the sqlite3_valueso that the sqlite3_value specified in the parameter may change orbe deallocated after sqlite3_result_value() returns without harm.A protected sqlite3_value object may always be used where anunprotected sqlite3_value object is required, so eitherkind of sqlite3_value object can be used with this interface.
If these routines are called from within the different threadthan the one containing the application-defined function that receivedthe sqlite3_context pointer, the results are undefined.
Obtain Values For URI Parametersconst char *sqlite3_uri_parameter(const char *zFilename, const char *zParam);int sqlite3_uri_boolean(const char *zFile, const char *zParam, int bDefault);sqlite3_int64 sqlite3_uri_int64(const char*, const char*, sqlite3_int64);
These are utility routines, useful to VFS implementations, that checkto see if a database file was a URI that contained a specific queryparameter, and if so obtains the value of that query parameter.
If F is the database filename pointer passed into the xOpen() method ofa VFS implementation when the flags parameter to xOpen() has one ormore of the SQLITE_OPEN_URI or SQLITE_OPEN_MAIN_DB bits set andP is the name of the query parameter, thensqlite3_uri_parameter(F,P) returns the value of the Pparameter if it exists or a NULL pointer if P does not appear as aquery parameter on F. If P is a query parameter of Fhas no explicit value, then sqlite3_uri_parameter(F,P) returnsa pointer to an empty string.
The sqlite3_uri_boolean(F,P,B) routine assumes that P is a booleanparameter and returns true (1) or false (0) according to the valueof P. The value of P is true if it is "yes" or "true" or "on" ora non-zero number and is false otherwise. If P is not a query parameteron F then sqlite3_uri_boolean(F,P,B) returns (B!=0).
The sqlite3_uri_int64(F,P,D) routine converts the value of P into a64-bit signed integer and returns that integer, or D if P does notexist. If the value of P is something other than an integer, thenzero is returned.
If F is a NULL pointer, then sqlite3_uri_parameter(F,P) returns NULL andsqlite3_uri_boolean(F,P,B) returns B. If F is not a NULL pointer andis not a database file pathname pointer that SQLite passed into the xOpenVFS method, then the behavior of this routine is undefined and probablyundesirable.
Obtaining SQL Function Parameter Valuesconst void *sqlite3_value_blob(sqlite3_value*);int sqlite3_value_bytes(sqlite3_value*);int sqlite3_value_bytes16(sqlite3_value*);double sqlite3_value_double(sqlite3_value*);int sqlite3_value_int(sqlite3_value*);sqlite3_int64 sqlite3_value_int64(sqlite3_value*);const unsigned char *sqlite3_value_text(sqlite3_value*);const void *sqlite3_value_text16(sqlite3_value*);const void *sqlite3_value_text16le(sqlite3_value*);const void *sqlite3_value_text16be(sqlite3_value*);int sqlite3_value_type(sqlite3_value*);int sqlite3_value_numeric_type(sqlite3_value*);
The C-language implementation of SQL functions and aggregates usesthis set of interface routines to access the parameter values onthe function or aggregate.
The xFunc (for scalar functions) or xStep (for aggregates) parametersto sqlite3_create_function() and sqlite3_create_function16()define callbacks that implement the SQL functions and aggregates.The 3rd parameter to these callbacks is an array of pointers toprotected sqlite3_value objects. There is one sqlite3_value object foreach parameter to the SQL function. These routines are used toextract values from the sqlite3_value objects.
These routines work only with protected sqlite3_value objects.Any attempt to use these routines on an unprotected sqlite3_valueobject results in undefined behavior.
These routines work just like the corresponding column access functionsexcept that these routines take a single protected sqlite3_value objectpointer instead of a sqlite3_stmt* pointer and an integer column number.
The sqlite3_value_text16() interface extracts a UTF-16 stringin the native byte-order of the host machine. Thesqlite3_value_text16be() and sqlite3_value_text16le() interfacesextract UTF-16 strings as big-endian and little-endian respectively.
The sqlite3_value_numeric_type() interface attempts to applynumeric affinity to the value. This means that an attempt ismade to convert the value to an integer or floating point. Ifsuch a conversion is possible without loss of information (in otherwords, if the value is a string that looks like a number)then the conversion is performed. Otherwise no conversion occurs.The datatype after conversion is returned.
Please pay particular attention to the fact that the pointer returnedfrom sqlite3_value_blob(), sqlite3_value_text(), orsqlite3_value_text16() can be invalidated by a subsequent call tosqlite3_value_bytes(), sqlite3_value_bytes16(), sqlite3_value_text(),or sqlite3_value_text16().
These routines must be called from the same thread asthe SQL function that supplied the sqlite3_value* parameters.
Virtual File System Objectssqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);int sqlite3_vfs_register(sqlite3_vfs*, int makeDflt);int sqlite3_vfs_unregister(sqlite3_vfs*);
A virtual filesystem (VFS) is an sqlite3_vfs objectthat SQLite uses to interactwith the underlying operating system. Most SQLite builds come with asingle default VFS that is appropriate for the host computer.New VFSes can be registered and existing VFSes can be unregistered.The following interfaces are provided.
The sqlite3_vfs_find() interface returns a pointer to a VFS given its name.Names are case sensitive.Names are zero-terminated UTF-8 strings.If there is no match, a NULL pointer is returned.If zVfsName is NULL then the default VFS is returned.
New VFSes are registered with sqlite3_vfs_register().Each new VFS becomes the default VFS if the makeDflt flag is set.The same VFS can be registered multiple times without injury.To make an existing VFS into the default VFS, register it againwith the makeDflt flag set. If two different VFSes with thesame name are registered, the behavior is undefined. If aVFS is registered with a name that is NULL or an empty string,then the behavior is undefined.
Unregister a VFS with the sqlite3_vfs_unregister() interface.If the default VFS is unregistered, another VFS is chosen asthe default. The choice for the new VFS is arbitrary.
Binding Values To Prepared Statementsint sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*));int sqlite3_bind_double(sqlite3_stmt*, int, double);int sqlite3_bind_int(sqlite3_stmt*, int, int);int sqlite3_bind_int64(sqlite3_stmt*, int, sqlite3_int64);int sqlite3_bind_null(sqlite3_stmt*, int);int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int, void(*)(void*));int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*);int sqlite3_bind_zeroblob(sqlite3_stmt*, int, int n);
In the SQL statement text input to sqlite3_prepare_v2() and its variants,literals may be replaced by a parameter that matches one of followingtemplates:
? ?NNN :VVV @VVV $VVVIn the templates above, NNN represents an integer literal,and VVV represents an alphanumeric identifier. The values of theseparameters (also called "host parameter names" or "SQL parameters")can be set using the sqlite3_bind_*() routines defined here.
The first argument to the sqlite3_bind_*() routines is alwaysa pointer to the sqlite3_stmt object returned fromsqlite3_prepare_v2() or its variants.
The second argument is the index of the SQL parameter to be set.The leftmost SQL parameter has an index of 1. When the same namedSQL parameter is used more than once, second and subsequentoccurrences have the same index as the first occurrence.The index for named parameters can be looked up using thesqlite3_bind_parameter_index() API if desired. The indexfor "?NNN" parameters is the value of NNN.The NNN value must be between 1 and the sqlite3_limit()parameter SQLITE_LIMIT_VARIABLE_NUMBER (default value: 999).
The third argument is the value to bind to the parameter.
In those routines that have a fourth argument, its value is thenumber of bytes in the parameter. To be clear: the value is thenumber of bytes in the value, not the number of characters.If the fourth parameter is negative, the length of the string isthe number of bytes up to the first zero terminator.If a non-negative fourth parameter is provided to sqlite3_bind_text()or sqlite3_bind_text16() then that parameter must be the byte offsetwhere the NUL terminator would occur assuming the string were NULterminated. If any NUL characters occur at byte offsets less thanthe value of the fourth parameter then the resulting string value willcontain embedded NULs. The result of expressions involving stringswith embedded NULs is undefined.
The fifth argument to sqlite3_bind_blob(), sqlite3_bind_text(), andsqlite3_bind_text16() is a destructor used to dispose of the BLOB orstring after SQLite has finished with it. The destructor is calledto dispose of the BLOB or string even if the call to sqlite3_bind_blob(),sqlite3_bind_text(), or sqlite3_bind_text16() fails.If the fifth argument isthe special value SQLITE_STATIC, then SQLite assumes that theinformation is in static, unmanaged space and does not need to be freed.If the fifth argument has the value SQLITE_TRANSIENT, thenSQLite makes its own private copy of the data immediately, beforethe sqlite3_bind_*() routine returns.
The sqlite3_bind_zeroblob() routine binds a BLOB of length N thatis filled with zeroes. A zeroblob uses a fixed amount of memory(just an integer to hold its size) while it is being processed.Zeroblobs are intended to serve as placeholders for BLOBs whosecontent is later written usingincremental BLOB I/O routines.A negative value for the zeroblob results in a zero-length BLOB.
If any of the sqlite3_bind_*() routines are called with a NULL pointerfor the prepared statement or with a prepared statement for whichsqlite3_step() has been called more recently than sqlite3_reset(),then the call will return SQLITE_MISUSE. If any sqlite3_bind_()routine is passed a prepared statement that has been finalized, theresult is undefined and probably harmful.
Bindings are not cleared by the sqlite3_reset() routine.Unbound parameters are interpreted as NULL.
The sqlite3_bind_* routines return SQLITE_OK on success or anerror code if anything goes wrong.SQLITE_RANGE is returned if the parameterindex is out of range. SQLITE_NOMEM is returned if malloc() fails.
See also: sqlite3_bind_parameter_count(),sqlite3_bind_parameter_name(), and sqlite3_bind_parameter_index().
Compiling An SQL Statementint sqlite3_prepare( sqlite3 *db, /* Database handle */ const char *zSql, /* SQL statement, UTF-8 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const char **pzTail /* OUT: Pointer to unused portion of zSql */);int sqlite3_prepare_v2( sqlite3 *db, /* Database handle */ const char *zSql, /* SQL statement, UTF-8 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const char **pzTail /* OUT: Pointer to unused portion of zSql */);int sqlite3_prepare16( sqlite3 *db, /* Database handle */ const void *zSql, /* SQL statement, UTF-16 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const void **pzTail /* OUT: Pointer to unused portion of zSql */);int sqlite3_prepare16_v2( sqlite3 *db, /* Database handle */ const void *zSql, /* SQL statement, UTF-16 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const void **pzTail /* OUT: Pointer to unused portion of zSql */);
To execute an SQL query, it must first be compiled into a byte-codeprogram using one of these routines.
The first argument, "db", is a database connection obtained from aprior successful call to sqlite3_open(), sqlite3_open_v2() orsqlite3_open16(). The database connection must not have been closed.
The second argument, "zSql", is the statement to be compiled, encodedas either UTF-8 or UTF-16. The sqlite3_prepare() and sqlite3_prepare_v2()interfaces use UTF-8, and sqlite3_prepare16() and sqlite3_prepare16_v2()use UTF-16.
If the nByte argument is less than zero, then zSql is read up to thefirst zero terminator. If nByte is non-negative, then it is the maximumnumber of bytes read from zSql. When nByte is non-negative, thezSql string ends at either the first '\000' or '\u0000' character orthe nByte-th byte, whichever comes first. If the caller knowsthat the supplied string is nul-terminated, then there is a smallperformance advantage to be gained by passing an nByte parameter thatis equal to the number of bytes in the input string includingthe nul-terminator bytes as this saves SQLite from having tomake a copy of the input string.
If pzTail is not NULL then *pzTail is made to point to the first bytepast the end of the first SQL statement in zSql. These routines onlycompile the first statement in zSql, so *pzTail is left pointing towhat remains uncompiled.
*ppStmt is left pointing to a compiled prepared statement that can beexecuted using sqlite3_step(). If there is an error, *ppStmt is setto NULL. If the input text contains no SQL (if the input is an emptystring or a comment) then *ppStmt is set to NULL.The calling procedure is responsible for deleting the compiledSQL statement using sqlite3_finalize() after it has finished with it.ppStmt may not be NULL.
On success, the sqlite3_prepare() family of routines return SQLITE_OK;otherwise an error code is returned.
The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces arerecommended for all new programs. The two older interfaces are retainedfor backwards compatibility, but their use is discouraged.In the "v2" interfaces, the prepared statementthat is returned (the sqlite3_stmt object) contains a copy of theoriginal SQL text. This causes the sqlite3_step() interface tobehave differently in three ways:
int sqlite3_create_function( sqlite3 *db, const char *zFunctionName, int nArg, int eTextRep, void *pApp, void (*xFunc)(sqlite3_context*,int,sqlite3_value**), void (*xStep)(sqlite3_context*,int,sqlite3_value**), void (*xFinal)(sqlite3_context*));int sqlite3_create_function16( sqlite3 *db, const void *zFunctionName, int nArg, int eTextRep, void *pApp, void (*xFunc)(sqlite3_context*,int,sqlite3_value**), void (*xStep)(sqlite3_context*,int,sqlite3_value**), void (*xFinal)(sqlite3_context*));int sqlite3_create_function_v2( sqlite3 *db, const char *zFunctionName, int nArg, int eTextRep, void *pApp, void (*xFunc)(sqlite3_context*,int,sqlite3_value**), void (*xStep)(sqlite3_context*,int,sqlite3_value**), void (*xFinal)(sqlite3_context*), void(*xDestroy)(void*));
These functions (collectively known as "function creation routines")are used to add SQL functions or aggregates or to redefine the behaviorof existing SQL functions or aggregates. The only differences betweenthese routines are the text encoding expected forthe second parameter (the name of the function being created)and the presence or absence of a destructor callback forthe application data pointer.
The first parameter is the database connection to which the SQLfunction is to be added. If an application uses more than one databaseconnection then application-defined SQL functions must be addedto each database connection separately.
The second parameter is the name of the SQL function to be created orredefined. The length of the name is limited to 255 bytes in a UTF-8representation, exclusive of the zero-terminator. Note that the namelength limit is in UTF-8 bytes, not characters nor UTF-16 bytes.Any attempt to create a function with a longer namewill result in SQLITE_MISUSE being returned.
The third parameter (nArg)is the number of arguments that the SQL function oraggregate takes. If this parameter is -1, then the SQL function oraggregate may take any number of arguments between 0 and the limitset by sqlite3_limit(SQLITE_LIMIT_FUNCTION_ARG). If the thirdparameter is less than -1 or greater than 127 then the behavior isundefined.
The fourth parameter, eTextRep, specifies whattext encoding this SQL function prefers forits parameters. Every SQL function implementation must be able to workwith UTF-8, UTF-16le, or UTF-16be. But some implementations may bemore efficient with one encoding than another. An application mayinvoke sqlite3_create_function() or sqlite3_create_function16() multipletimes with the same function but with different values of eTextRep.When multiple implementations of the same function are available, SQLitewill pick the one that involves the least amount of data conversion.If there is only a single implementation which does not care what textencoding is used, then the fourth argument should be SQLITE_ANY.
The fifth parameter is an arbitrary pointer. The implementation of thefunction can gain access to this pointer using sqlite3_user_data().
The sixth, seventh and eighth parameters, xFunc, xStep and xFinal, arepointers to C-language functions that implement the SQL function oraggregate. A scalar SQL function requires an implementation of the xFunccallback only; NULL pointers must be passed as the xStep and xFinalparameters. An aggregate SQL function requires an implementation of xStepand xFinal and NULL pointer must be passed for xFunc. To delete an existingSQL function or aggregate, pass NULL pointers for all three functioncallbacks.
If the ninth parameter to sqlite3_create_function_v2() is not NULL,then it is destructor for the application data pointer.The destructor is invoked when the function is deleted, either by beingoverloaded or when the database connection closes.The destructor is also invoked if the call tosqlite3_create_function_v2() fails.When the destructor callback of the tenth parameter is invoked, itis passed a single argument which is a copy of the application datapointer which was the fifth parameter to sqlite3_create_function_v2().
It is permitted to register multiple implementations of the samefunctions with the same name but with either differing numbers ofarguments or differing preferred text encodings. SQLite will usethe implementation that most closely matches the way in which theSQL function is used. A function implementation with a non-negativenArg parameter is a better match than a function implementation witha negative nArg. A function where the preferred text encodingmatches the database encoding is a bettermatch than a function where the encoding is different.A function where the encoding difference is between UTF16le and UTF16beis a closer match than a function where the encoding difference isbetween UTF8 and UTF16.
Built-in functions may be overloaded by new application-defined functions.
An application-defined function is permitted to call otherSQLite interfaces. However, such calls must notclose the database connection nor finalize or reset the preparedstatement in which the function is running.
Test For Auto-Commit Modeint sqlite3_get_autocommit(sqlite3*);
The sqlite3_get_autocommit() interface returns non-zero orzero if the given database connection is or is not in autocommit mode,respectively. Autocommit mode is on by default.Autocommit mode is disabled by a BEGIN statement.Autocommit mode is re-enabled by a COMMIT or ROLLBACK.
If certain kinds of errors occur on a statement within a multi-statementtransaction (errors including SQLITE_FULL, SQLITE_IOERR,SQLITE_NOMEM, SQLITE_BUSY, and SQLITE_INTERRUPT) then thetransaction might be rolled back automatically. The only way tofind out whether SQLite automatically rolled back the transaction afteran error is to use this function.
If another thread changes the autocommit status of the databaseconnection while this routine is running, then the return valueis undefined.
Result Values From A Queryconst void *sqlite3_column_blob(sqlite3_stmt*, int iCol);int sqlite3_column_bytes(sqlite3_stmt*, int iCol);int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);double sqlite3_column_double(sqlite3_stmt*, int iCol);int sqlite3_column_int(sqlite3_stmt*, int iCol);sqlite3_int64 sqlite3_column_int64(sqlite3_stmt*, int iCol);const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);int sqlite3_column_type(sqlite3_stmt*, int iCol);sqlite3_value *sqlite3_column_value(sqlite3_stmt*, int iCol);
These routines form the "result set" interface.
These routines return information about a single column of the currentresult row of a query. In every case the first argument is a pointerto the prepared statement that is being evaluated (the sqlite3_stmt*that was returned from sqlite3_prepare_v2() or one of its variants)and the second argument is the index of the column for which informationshould be returned. The leftmost column of the result set has the index 0.The number of columns in the result can be determined usingsqlite3_column_count().
If the SQL statement does not currently point to a valid row, or if thecolumn index is out of range, the result is undefined.These routines may only be called when the most recent call tosqlite3_step() has returned SQLITE_ROW and neithersqlite3_reset() nor sqlite3_finalize() have been called subsequently.If any of these routines are called after sqlite3_reset() orsqlite3_finalize() or after sqlite3_step() has returnedsomething other than SQLITE_ROW, the results are undefined.If sqlite3_step() or sqlite3_reset() or sqlite3_finalize()are called from a different thread while any of these routinesare pending, then the results are undefined.
The sqlite3_column_type() routine returns thedatatype code for the initial data typeof the result column. The returned value is one of SQLITE_INTEGER,SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB, or SQLITE_NULL. The valuereturned by sqlite3_column_type() is only meaningful if no typeconversions have occurred as described below. After a type conversion,the value returned by sqlite3_column_type() is undefined. Futureversions of SQLite may change the behavior of sqlite3_column_type()following a type conversion.
If the result is a BLOB or UTF-8 string then the sqlite3_column_bytes()routine returns the number of bytes in that BLOB or string.If the result is a UTF-16 string, then sqlite3_column_bytes() convertsthe string to UTF-8 and then returns the number of bytes.If the result is a numeric value then sqlite3_column_bytes() usessqlite3_snprintf() to convert that value to a UTF-8 string and returnsthe number of bytes in that string.If the result is NULL, then sqlite3_column_bytes() returns zero.
If the result is a BLOB or UTF-16 string then the sqlite3_column_bytes16()routine returns the number of bytes in that BLOB or string.If the result is a UTF-8 string, then sqlite3_column_bytes16() convertsthe string to UTF-16 and then returns the number of bytes.If the result is a numeric value then sqlite3_column_bytes16() usessqlite3_snprintf() to convert that value to a UTF-16 string and returnsthe number of bytes in that string.If the result is NULL, then sqlite3_column_bytes16() returns zero.
The values returned by sqlite3_column_bytes() andsqlite3_column_bytes16() do not include the zero terminators at the endof the string. For clarity: the values returned bysqlite3_column_bytes() and sqlite3_column_bytes16() are the number ofbytes in the string, not the number of characters.
Strings returned by sqlite3_column_text() and sqlite3_column_text16(),even empty strings, are always zero-terminated. The returnvalue from sqlite3_column_blob() for a zero-length BLOB is a NULL pointer.
The object returned by sqlite3_column_value() is anunprotected sqlite3_value object. An unprotected sqlite3_value objectmay only be used with sqlite3_bind_value() and sqlite3_result_value().If the unprotected sqlite3_value object returned bysqlite3_column_value() is used in any other way, including callsto routines like sqlite3_value_int(), sqlite3_value_text(),or sqlite3_value_bytes(), then the behavior is undefined.
These routines attempt to convert the value where appropriate. Forexample, if the internal representation is FLOAT and a text resultis requested, sqlite3_snprintf() is used internally to perform theconversion automatically. The following table details the conversionsthat are applied:
Internal
Type Requested
Type Conversion NULL INTEGER Result is 0 NULL FLOAT Result is 0.0 NULL TEXT Result is NULL pointer NULL BLOB Result is NULL pointer INTEGER FLOAT Convert from integer to float INTEGER TEXT ASCII rendering of the integer INTEGER BLOB Same as INTEGER->TEXT FLOAT INTEGER Convert from float to integer FLOAT TEXT ASCII rendering of the float FLOAT BLOB Same as FLOAT->TEXT TEXT INTEGER Use atoi() TEXT FLOAT Use atof() TEXT BLOB No change BLOB INTEGER Convert to TEXT then use atoi() BLOB FLOAT Convert to TEXT then use atof() BLOB TEXT Add a zero terminator if needed
The table above makes reference to standard C library functions atoi()and atof(). SQLite does not really use these functions. It has itsown equivalent internal routines. The atoi() and atof() names areused in the table for brevity and because they are familiar to mostC programmers.
Note that when type conversions occur, pointers returned by priorcalls to sqlite3_column_blob(), sqlite3_column_text(), and/orsqlite3_column_text16() may be invalidated.Type conversions and pointer invalidations might occurin the following cases:
The initial content is a BLOB and sqlite3_column_text() orsqlite3_column_text16() is called. A zero-terminator mightneed to be added to the string. The initial content is UTF-8 text and sqlite3_column_bytes16() orsqlite3_column_text16() is called. The content must be convertedto UTF-16. The initial content is UTF-16 text and sqlite3_column_bytes() orsqlite3_column_text() is called. The content must be convertedto UTF-8.Conversions between UTF-16be and UTF-16le are always done in place and donot invalidate a prior pointer, though of course the content of the bufferthat the prior pointer references will have been modified. Other kindsof conversion are done in place when it is possible, but sometimes theyare not possible and in those cases prior pointers are invalidated.
The safest and easiest to remember policy is to invoke these routinesin one of the following ways:
sqlite3_column_text() followed by sqlite3_column_bytes()sqlite3_column_blob() followed by sqlite3_column_bytes()sqlite3_column_text16() followed by sqlite3_column_bytes16()In other words, you should call sqlite3_column_text(),sqlite3_column_blob(), or sqlite3_column_text16() first to force the resultinto the desired format, then invoke sqlite3_column_bytes() orsqlite3_column_bytes16() to find the size of the result. Do not mix callsto sqlite3_column_text() or sqlite3_column_blob() with calls tosqlite3_column_bytes16(), and do not mix calls to sqlite3_column_text16()with calls to sqlite3_column_bytes().
The pointers returned are valid until a type conversion occurs asdescribed above, or until sqlite3_step() or sqlite3_reset() orsqlite3_finalize() is called. The memory space used to hold stringsand BLOBs is freed automatically. Do not pass the pointers returnedsqlite3_column_blob(), sqlite3_column_text(), etc. intosqlite3_free().
If a memory allocation error occurs during the evaluation of anyof these routines, a default value is returned. The default valueis either the integer 0, the floating point number 0.0, or a NULLpointer. Subsequent calls to sqlite3_errcode() will returnSQLITE_NOMEM.
Enable Or Disable Shared Pager Cacheint sqlite3_enable_shared_cache(int);
This routine enables or disables the sharing of the database cacheand schema data structures between connectionsto the same database. Sharing is enabled if the argument is trueand disabled if the argument is false.
Cache sharing is enabled and disabled for an entire process.This is a change as of SQLite version 3.5.0. In prior versions of SQLite,sharing was enabled or disabled for each thread separately.
The cache sharing mode set by this interface effects all subsequentcalls to sqlite3_open(), sqlite3_open_v2(), and sqlite3_open16().Existing database connections continue use the sharing modethat was in effect at the time they were opened.
This routine returns SQLITE_OK if shared cache was enabled or disabledsuccessfully. An error code is returned otherwise.
Shared cache is disabled by default. But this might change infuture releases of SQLite. Applications that care about sharedcache setting should set it explicitly.
See Also: SQLite Shared-Cache Mode