SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.

The SQLite distribution comes with a standalone command-line access program (sqlite) that can be used to administer an SQLite database and which serves as an example of how to use the SQLite library.

Create A New Database:

� At a shell or DOS prompt, enter: "sqlite3 test.db". This will create a new database named "test.db". (You can use a different name if you like.)
� Enter SQL commands at the prompt to create and populate the new database.

Write Programs That Use SQLite

Below is a simple TCL program that demonstrates how to use the TCL interface to SQLite. The program executes the SQL statements given as the second argument on the database defined by the first argument. The commands to watch for are the sqlite3 command on line 7 which opens an SQLite database and creates a new TCL command named "db" to access that database, the invocation of the db command on line 8 to execute SQL commands against the database, and the closing of the database connection on the last line of the script.

#!/usr/bin/tclsh
if {$argc!=2} {
puts stderr "Usage: %s DATABASE SQL-STATEMENT"
exit 1
}
load /usr/lib/tclsqlite3.so Sqlite3
sqlite3 db [lindex $argv 0]
db eval [lindex $argv 1] x {
foreach v $x(*) {
puts "$v = $x($v)"
}
puts ""
}
db close

Product's homepage

Here are some key features of "SQLite":

· Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures.
· Zero-configuration - no setup or administration needed.
· Implements most of SQL92. (Features not supported)
· A complete database is stored in a single disk file.
· Database files can be freely shared between machines with different byte orders.
· Supports databases up to 2 terabytes (241 bytes) in size.
· Sizes of strings and BLOBs limited only by available memory.
· Small code footprint: less than 30K lines of C code, less than 250KB code space (gcc on 486)
· Faster than popular client/server database engines for most common operations.
· Simple, easy to use API.
· TCL bindings included. Bindings for many other languages available separately.
· Well-commented source code with over 95% test coverage.
· Self-contained: no external dependencies.
· Sources are in the public domain. Use for any purpose.

What's New in This Release: [ read full changelog ]

· The SQLITE_CONFIG_PCACHE mechanism has been replaced with SQLITE_CONFIG_PCACHE2. If you do not know what this mechanism is (it is an extreme corner-case and is seldom used) then this change will not effect you in the least.

· The default schema format number for new database files has changed from 1 to 4. SQLite has been able to generate and read database files using schema format 4 for six years. But up unto now, the default schema format has been 1 so that older versions of SQLite could read and write databases generated by newer versions of SQLite. But those older versions of SQLite have become so scarce now that it seems reasonable to make the new format the default.

· SQLite is changing some of the assumptions it makes above the behavior of disk drives and flash memory devices during a sudden power loss. This change is completely transparent to applications. Read about the powersafe overwrite property for additional information.

Lots of new interfaces have been added in this release:

· sqlite3_db_release_memory()
· PRAGMA shrink_memory
· sqlite3_db_filename()
· sqlite3_stmt_busy()
· sqlite3_uri_boolean()
· sqlite3_uri_int64()

· The PRAGMA cache_size statement has been enhanced. Formerly, you would use this statement to tell SQLite how many pages of the database files it should hold in its cache at once. The total memory requirement would depend on the database page size. Now, if you give PRAGMA cache_size a negative value -N, it will allocate roughly N kibibytes of memory to cache, divided up according to page size. This enhancement allows programs to more easily control their memory usage.

· There have been several obscure bug fixes. One noteworthy bug, ticket ff5be73dee, could in theory result in a corrupt database file if a power loss occurred at just the wrong moment on an unusually cantankerous disk drive. But that is mostly a theoretical concern and is very unlikely to happen in practice. The bug was found during laboratory testing and has never been observed to occur in the wild.