SQLite

3.7.11

Released on 20 Mar 2012
Project description.

SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is the most widely deployed database in the world with more applications than we can count, including several high-profile projects.

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views, is contained in a single disk file. The database file format is cross-platform - you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures. These features make SQLite a popular choice as an Application File Format.

SQLite 3.7.11 Changelog
  • Enhance the INSERT syntax to allow multiple rows to be inserted via the VALUES clause.
  • Enhance the CREATE VIRTUAL TABLE command to support the IF NOT EXISTS clause.
  • Added the sqlite3_stricmp() interface as a counterpart to sqlite3_strnicmp().
  • Added the sqlite3_db_readonly() interface.
  • Added the SQLITE_FCNTL_PRAGMA file control, giving VFS implementations the ability to add new PRAGMA statements or to override built-in PRAGMAs.
  • Queries of the form: "SELECT max(x), y FROM table" returns the value of y on the same row that contains the maximum x value.
  • Added support for the FTS4 languageid option.
  • Documented support for the FTS4 content option. This feature has actually been in the code since version 3.7.9 but is only now considered to be officially supported.
  • Pending statements no longer block ROLLBACK. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK.
  • Improvements to the handling of CSV inputs in the command-line shell
  • Fix a bug introduced in version 3.7.10 that might cause a LEFT JOIN to be incorrectly converted into an INNER JOIN if the WHERE clause indexable terms connected by OR.
  • SQLITE_SOURCE_ID: "2012-03-20 11:35:50 00bb9c9ce4f465e6ac321ced2a9d0062dc364669"
  • SHA1 for sqlite3.c: d460d7eda3a9dccd291aed2a9fda868b9b120a10