Discover how to use and probe a SQLite database

Pragmas and Quotation Marks

A PRAGMA statement is a SQL extension that changes the general high-level behavior of the SQLite library or checks the status and properties of a data structure (Figure 2). One example of pragma is

Figure 2: SQLite pragmas are high-level directives that change the behavior of SQLite. In DB Browser, you can easily check their values and change them as needed.
PRAGMA auto_vacuum = FULL;

which tells SQLite to enable automatic execution of the VACUUM command, which then rebuilds and compacts database files to save disk space.

SQLite uses single quotes to enclose literal strings and double quotes for keywords or column or table names. Assuming your database has a column named platform, you may write:


But the first statement means "[do something] if the field called platform has the value linux"; the second statement says "[do something] if the field called platform has the same value as the field called linux."


SQLite metacommands, called dot commands because they begin with a dot, don't add to or fetch data from SQLite tables. They provide high-level information, shortcuts to frequently used metaqueries, or change the way query results are presented, as shown in Table 1.

Table 1

Some SQLite Metacommands

Dot Command



List all active databases


List all metacommands

.import FILE TABLE

Import data from FILE into TABLE

.output FILE

Send output to FILE

.output stdout

Send output to the screen

.read FILE

Execute the SQL commands in FILE


List the complete structure of the current databases

.schema TABLE

Only show structure of the requested table

.separator STRING

Change column separator


Show current settings


List all the database tables

The same table also shows how to add comments to your SQLite code: you can use two dashes (--), which means the parser ignores everything that follows to the end of the line. For multiline comments, you enclose text between the strings /* and */, as you would in C programs.

Data Types

In a SQLite table, each column can store data of different types, but each column has its own preferred storage class (Figure 3). This class is assigned to each column when you create a table, such as:

  title   TEXT NOT NULL,
  author  TEXT NOT NULL,
  price   REAL NOT NULL);
Figure 3: Each column inside a SQLite table has a data type, which is specified when you create the table. You can do this directly by writing SQL code (bottom), or you can use DB Browser to generate the same code for you (top).

The books table has four columns: the first, which is also the index, is an integer; the last column is a floating-point number, and the others are text strings.

Dates deserve an extra word because they can be stored in three interchangeable formats:

  • REAL – the number of days since noon, Greenwich mean time, on November 24, 4714BC
  • INTEGER – the number of seconds since 1970-01-01 00:00:00 UTC
  • TEXT – a string (e.g., "YYYY-MM-DD HH:MM:SS.SSS")

Speaking of text strings, beware! Although the SQLite core library can store strings with any encoding, by default it correctly compares and orders only ASCII characters in a case-insensitive way. This design choice makes the SQLite core code as small and fast as possible. Support for non-ASCII characters is delegated to external libraries, which in practice may be linked already into the SQLite software packaged for your Linux distribution. SQLite can also store BLOBs, which are raw sequences of bytes (e.g., images).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More