Recent SQLite News

Small. Fast. Reliable.
Choose any three.

About Sitemap Documentation Download License News Support |

## Recent News

### 2013-12-06 - Release 3.8.2

> SQLite version 3.8.2 is a regularly scheduled maintenance release. Upgrading from the previous release is optional.

> Version 3.8.2 adds support for WITHOUT ROWID tables. This is a significant extension to SQLite. Database files that contain WITHOUT ROWID tables are not readable or writable by prior versions of SQLite, however databases that do not use WITHOUT ROWID tables are fully backwards and forwards compatible.

> The 3.8.2 release contains a potentially incompatible change. In all prior versions of SQLite, a cast from a very large positive floating point number into an integer resulted in the most negative integer. In other words, CAST(+99.9e99 to INT) would yield -9223372036854775808. This behavior came about because it is what x86/x64 hardware does for the equivalent cast in the C language. But the behavior is bizarre. And so it has been changed effective with this release so that a cast from a floating point number into an integer returns the integer between the floating point value and zero that is closest to the floating point value. Hence, CAST(+99.9e99 to INT) now returns +9223372036854775807. Since routines like sqlite3_column_int64() do an implicit cast if the value being accessed is really a floating point number, they are also affected by this change.

> Besides the two changes mentioned above, the 3.8.2 release also includes a number of performance enhancements. The skip-scan optimization is now available for databases that have been processed by ANALYZE. Constant SQL functions are now factored out of inner loops, which can result in a significant speedup for queries that contain WHERE clause terms like "date>datetime('now','-2 days')". And various high-runner internal routines have been refactored for reduced CPU load.

### 2013-10-17 - Release 3.8.1

> SQLite version 3.8.1 is a regularly scheduled maintenance release. Upgrading from the previous release is optional, though you should upgrade if you are using partial indices as there was a bug related to partial indices in the previous release that could result in an incorrect answer for count(*) queries.

> The next generation query planner that was premiered in the previous release continues to work well. The new query planner has been tweaked slightly in the current release to help it make better decisions in some cases, but is largely unchanged. Two new SQL functions, likelihood() and unlikely(), have been added to allow developers to give hints to the query planner without forcing the query planner into a particular decision.

> Version 3.8.1 is the first SQLite release to take into account the estimated size of table and index rows when choosing a query plan. Row size estimates are based on the declared datatypes of columns. For example, a column of type VARCHAR(1000) is assumed to use much more space than a column of type INT. The datatype-based row size estimate can be overridden by appending a term of the form "sz=NNN" (where NNN is the average row size in bytes) to the end of the sqlite_stat1.stat record for a table or index. Currently, row sizes are only used to help the query planner choose between a table or one of its indices when doing a table scan or a count(*) operation, though future releases are likely to use the estimated row size in other contexts as well. The new PRAGMA stats statement can be used to view row size estimates.

> Version 3.8.1 adds the SQLITE_ENABLE_STAT4 compile-time option. STAT4 is very similar to STAT3 in that it uses samples from indices to try to guess how many rows of the index will be satisfy by WHERE clause constraints. The difference is that STAT4 samples all columns of the index whereas the older STAT3 only sampled the left-most column. Users of STAT3 are encouraged to upgrade to STAT4. Application developers should use STAT3 and STAT4 with caution since both options, by design, violate the query planner stability guarantee, making it more difficult to ensure uniform performance is widely-deployed and mass-produced embedded applications.

### 2013-09-03 - Release 3.8.0.2

> SQLite version 3.8.0.2 contains a one-line fix to a bug in the new optimization that tries to omit unused LEFT JOINs from a query.

### 2013-08-29 - Release 3.8.0.1

> SQLite version 3.8.0.1 fixes some obscure bugs that were uncovered by users in the 3.8.0 release. Changes from 3.8.0 are minimal.

### 2013-08-26 - Release 3.8.0

> Do not fear the zero!

> SQLite version 3.8.0 might easily have been called "3.7.18" instead. However, this release features the cutover of the next generation query planner or NGQP, and there is a small chance of breaking legacy programs that rely on undefined behavior in previous SQLite releases, and so the minor version number was incremented for that reason. But the risks are low and there is a query planner checklist is available to application developers to aid in avoiding problems.

> SQLite version 3.8.0 is actually one of the most heavily tested SQLite releases ever. Thousands and thousands of beta copies have be downloaded, and presumably tested, and there have been no problem reports.

> In addition to the next generation query planner, the 3.8.0 release adds support for partial indices, as well as several other new features. See the change log for further detail.

### 2013-05-20 - Release 3.7.17

> SQLite version 3.7.17 is a regularly schedule maintenance release. Visit the change log for a full explanation of the changes in this release.

> There are many bug fixes in version 3.7.17. But this does not indicate that 3.7.16 was a problematic release. All of the bugs in 3.7.17 are obscure and are unlikely to impact any particular application. And most of the bugs that are fixed in 3.7.17 predate 3.7.16 and have been in the code for years without ever before being noticed. Nevertheless, due to the large number of fixes, all users are encouraged to upgrade when possible.

### 2013-04-12 - Release 3.7.16.2

> SQLite version 3.7.16.2 fixes a long-standing flaw in the Windows OS interface that can result in database corruption under a rare race condition. See http://www.sqlite.org/src/info/7ff3120e4f for a full description of the problem.

> As far as we know, this bug has never been seen in the wild. The problem was discovered by the SQLite developers while writing stress tests for a separate component of SQLite. Those stress tests have not yet found any problems with the component they were intended to verify, but they did find the bug which is the subject of this patch release.

> Other than updates to version numbers, the only difference between this release and 3.7.16.1 is a two-character change in a single identifier, which is contained in the windows-specific OS interface logic. There are no changes in this release (other than version numbers) for platforms other than Windows.

### 2013-03-29 - Release 3.7.16.1

> SQLite version 3.7.16.1 is a bug fix release that fixes a few problems that were present in the previous releases.

> The primary motivation for version 3.7.16.1 is to fix a bug in the query optimizer that was introduced as part of version 3.7.15. The query optimizer was being a little overzealous in optimizing out some ORDER BY clauses, which resulted in sorting being omitted on occasions where sorting is required to get the correct answer. See ticket a179fe7465 for details.

> In addition to the ORDER BY fix, several other patches to fix obscure (and mostly harmless) bugs and to fix spelling errors in source code comments are also included in this release.

### 2013-03-18 - Release 3.7.16

> SQLite version 3.7.16 is a regularly scheduled release of SQLite. This release contains several language enhancements and improvements to the query optimizer. A list of the major enhancements and optimizations can be see on the change log.

> There was one important bug fix (see Ticket fc7bd6358f) that addresses an incorrect query result that could have occurred in a three-way join where the join constraints compared INTEGER columns to TEXT columns. This issue had been in the code for time out of mind and had never before been reported, so we surmise that it is very obscure. Nevertheless, all users are advised to upgrade to avoid any future problems associated with this issue.

### 2013-01-09 - Release 3.7.15.2

> SQLite version 3.7.15.2 is a patch release that fixes a single bug that was introduced in version version 3.7.15. The fix is a 4-character edit to a single line of code. Other than this 4-character change and the update of the version number, nothing has changed from version 3.7.15.1.

### 2012-12-19 - Release 3.7.15.1

> SQLite version 3.7.15.1 is a patch release that fixes a single bug that was introduced in version version 3.7.15. The fix involved changing two lines of code and adding a single assert(). This release also includes some new test cases to prevent a regression of the bug, and the version number is increased, of course. But otherwise, nothing has changed from version 3.7.15.

### 2012-12-12 - Release 3.7.15

> SQLite version 3.7.15 is a regularly schedule release of SQLite. This release contains several improvements to the query planner and optimizer and one important bug fix. This is the first release to officially support Windows 8 Phone.

> The important bug fix is a problem that can lead to segfaults when using shared cache mode on a schema that contains a COLLATE operator within a CHECK constraint or within a view. Collating functions are associated with individual database connections. But a pointer to the collating function was also being cached within expressions. If an expression was part of the schema and contained a cached collating function, it would point to the collating function in the database connection that originally parsed the schema. If that database connection closed while other database connections using the same shared cache continued to operate, they other database connections would try to use the deallocated collating function in the database connection that closed. The fix in version 3.7.15 was to not cache collating function pointers in the expression structure but instead look them up each time a new statement is prepared.

> This release also contains some important enhancements to the query planner which should (we hope) make some queries run faster. The enhancements include:

> 1. When doing a full-table scan, try to use an index instead of the original table, under the theory that indices contain less information and are thus smaller and hence require less disk I/O to scan.

> 2. Enhance the IN operator to allow it to make use of indices that have numeric affinity.

> 3. Do a better job of recognizing when an ORDER BY clause can be implemented using indices - especially in cases where the ORDER BY clause contains terms from two or more tables in a join.

### 2012-10-04 - Release 3.7.14.1

> SQLite version 3.7.14.1 is a patch release. Changes from the baseline version 3.7.14 are minimal and are restricted to fixing three bugs.

> One of the fixed bugs is a long-standing issue with the TCL interface. Another is an external compiler bug that SQLite merely works around and that only comes up if you are using the VisualStudio-2012 compiler to generate WinRT applications on ARM with optimizations enabled. The third problem is an SQLite core bug, introduced in version 3.7.14, that can cause a segfault if a query contains a LEFT JOIN that contains an OR in the ON clause.

### 2012-09-03 - Release 3.7.14

> SQLite version 3.7.14 is a regularly scheduled maintenance release of SQLite. The previous release continues to work well. Upgrading is optional.

> Version 3.7.14 drops native support for OS/2. We are not aware of any active projects that were using SQLite on OS/2 and since the SQLite developers had no way of testing on OS/2 it seemed like it was time to simply remove the OS/2 code from the SQLite tree. If there are OS/2 projects out there that still need SQLite support, they can continue to maintain their own private VFS which can be linked to SQLite at start-time using the sqlite3_vfs_register() interface.

> The sqlite3_close_v2() interface has been added. The sqlite3_close_v2() interface differs from sqlite3_close() in that it is designed to work better for host language that use a garbage collector. With the older sqlite3_close() interface, the associated prepared statements and sqlite3_backup objects must be destroyed before the database connection. With the newer sqlite3_close_v2() interface, the objects can be destroyed in any order.

> This release also includes performance improvements to the sort algorithm that is used to implement ORDER BY and CREATE INDEX. And the query planner has been enhanced to better use covering indices on queries that use OR terms in the WHERE clause.

### 2012-06-11 - Release 3.7.13

> SQLite version 3.7.13 adds support for WinRT and metro style applications for Microsoft Windows 8. The 3.7.13 release is coming sooner than is usual after the previous release in order to get this new capability into the hands of developers. To use SQLite in a metro style application, compile with the -DSQLITE_OS_WINRT flag. Because of the increased application security and safety requirements of WinRT, all database filenames should be full pathnames. Note that SQLite is not capable of accessing databases outside the installation directory and application data directory. This restriction is another security and safety feature of WinRT. Apart from these restrictions, SQLite should work exactly the same on WinRT as it does on every other system.

> Also in this release: when a database is opened using URI filenames and the mode=memory query parameter then the database is an in-memory database, just as if it had been named ":memory:". But, if shared cache mode is enabled, then all other database connections that specify the same URI filename will connect to the same in-memory database. This allows two or more database connections (in the same process) to share the same in-memory database.

> This release also includes some corner-case performance optimizations that are obscure yet significant to an important subset of SQLite users. Getting these performance optimizations into circulation quickly is yet another reason for making this release so soon following the previous.

> The next release of SQLite is scheduled to occur after the usual 2 or 3 month interval.

### 2012-05-22 - Patch Release 3.7.12.1

> SQLite version 3.7.12.1 is a patch release for version 3.7.12 that fixes a bug that was introduced in version 3.7.12 and that can cause a segfault for certain obscure nested aggregate queries. There are very few changes in 3.7.12.1, and upgrading is only needed for applications that do nested aggregate queries.

### 2012-05-14 - Version 3.7.12

> SQLite version 3.7.12 is a regularly scheduled maintenance release. This release contains several new optimizations and bug fixes and upgrading is recommended. See the change summary for details.

Old news...