Standard File Control Opcodes

Small. Fast. Reliable.
Choose any three.

About Sitemap Documentation Download License News Support |

## SQLite C Interface

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

These integer constants are opcodes for the xFileControl method of the sqlite3_io_methods object and for the sqlite3_file_control() interface.

The SQLITE_FCNTL_LOCKSTATE opcode is used for debugging. This opcode causes the xFileControl method to write the current state of the 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 capability is used during testing and only needs to be supported when SQLITE_TEST is defined.

The SQLITE_FCNTL_SIZE_HINT opcode is used by SQLite to give the VFS layer a hint of how large the database file will grow to be during the current transaction. This hint is not guaranteed to be accurate but it is often close. The underlying VFS might choose to preallocate database file space based on this hint in order to help writes to the database file run faster.

The SQLITE_FCNTL_CHUNK_SIZE opcode is used to request that the VFS extends and truncates the database file in chunks of a size specified by the user. The fourth argument to sqlite3_file_control() should point to an integer (type int) containing the new chunk-size to use for the nominated database. Allocating database file space in large chunks (say 1MB at a time), may reduce file-system fragmentation and improve performance on some systems.

The SQLITE_FCNTL_FILE_POINTER opcode is used to obtain a pointer to the sqlite3_file object associated with a particular database connection. See the sqlite3_file_control() documentation for additional information.

The SQLITE_FCNTL_SYNC_OMITTED opcode is generated internally by SQLite and sent to all VFSes in place of a call to the xSync method when the database connection has PRAGMA synchronous set to OFF. Some specialized VFSes need this signal in order to operate correctly when PRAGMA synchronous=OFF is set, but most VFSes do not need this signal and should silently ignore this opcode. Applications should not call sqlite3_file_control() with this opcode as doing so may disrupt the operation of the specialized VFSes that do require it.

The SQLITE_FCNTL_WIN32_AV_RETRY opcode is used to configure automatic retry counts and intervals for certain disk I/O operations for the windows VFS in order to work to provide robustness against anti-virus programs. By default, the windows VFS will retry file read, file write, and file delete opertions up to 10 times, with a delay of 25 milliseconds before the first retry and with the delay increasing by an additional 25 milliseconds with each subsequent retry. This opcode allows those to values (10 retries and 25 milliseconds of delay) to be adjusted. The values are changed for all database connections within the same process. The argument is a pointer to an array of two integers where the first integer i the new retry count and the second integer is the delay. If either integer is negative, then the setting is not changed but instead the prior value of that setting is written into the array entry, allowing the current retry settings to be interrogated. The zDbName parameter is ignored.

The SQLITE_FCNTL_PERSIST_WAL opcode is used to set or query the persistent Write AHead Log setting. By default, the auxiliary write ahead log and shared memory files used for transaction control are automatically deleted when the latest connection to the database closes. Setting persistent WAL mode causes those files to persist after close. Persisting the files is useful when other processes that do not have write permission on the directory containing the database file want to read the database file, as the WAL and shared memory files must exist in order for the database to be readable. The fourth parameter to sqlite3_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 persistent WAL mode. If the integer is -1, then it is overwritten with the current WAL persistence setting.

See also lists of Objects, Constants, and Functions.