Free online SQLITE to DBF converter

Legacy GIS, cadastral, accounting, and database programs may require a dBASE .dbf table instead of a SQLite database. Converting the data makes a selected SQLite table available to software that cannot read .sqlite or expects DBF field names, types, and encoding.

What the SQLite format is

SQLite is a self-contained relational database stored in one file, commonly using the extensions .sqlite, .sqlite3, or .db. Mobile apps, browsers, desktop utilities, embedded devices, and GIS programs use it because it requires no separate database server.

A SQLite file can contain multiple tables, indexes, views, triggers, and metadata. It is not equivalent to one spreadsheet, so conversion requires selecting a source table; related tables must usually be exported as separate DBF files.

What the DBF format is

DBF is the flat table format associated with dBASE. Older business systems, GIS applications, statistical programs, and database tools use it for exchanging rows and columns with a fixed schema. A Shapefile dataset commonly includes a DBF attribute table alongside its .shp and .shx files.

DBF is simple and widely supported by legacy software, but it does not preserve SQLite indexes, relationships, views, triggers, constraints, or transaction behavior. Traditional dBASE-compatible files generally restrict field names to 10 characters, use fixed field widths, provide limited numeric precision, and represent dates without time or timezone information.

How to convert the data

For a one-off conversion without installing software, use the converter on 101convert.com: select the SQLite file, choose the required table if table selection is available, start the conversion, and download the resulting .dbf. Confirm that the output contains the intended table; a SQLite database may contain several tables. Use a local method instead for confidential or very large databases.

For repeatable conversions or precise schema control, Python can read SQLite directly and write DBF:

1. Install Python and the DBF package:
   python -m pip install dbf
2. Inspect the database and table:
   sqlite3 source.sqlite
.tables
PRAGMA table_info(customers);
3. Create export_dbf.py, changing the table name, output name, fields, and selected column names as necessary:

import sqlite3
import dbf

source = "source.sqlite"
table_name = "customers"
output = "customers.dbf"

conn = sqlite3.connect(source)
conn.row_factory = sqlite3.Row
rows = conn.execute(f'SELECT * FROM "{table_name}"').fetchall()

fields = (
    "ID N(10,0); "
    "NAME C(80); "
    "EMAIL C(120); "
    "ACTIVE L; "
    "CREATED C(25)"
)

table = dbf.Table(output, fields, codepage="cp1252")
table.open(dbf.READ_WRITE)
try:
    for row in rows:
        table.append((
            row["id"],
            row["name"],
            row["email"],
            None if row["active"] is None else bool(row["active"]),
            row["created"]
        ))
finally:
    table.close()
    conn.close()

Run the script with python export_dbf.py. The DBF field definitions and tuple order must match the selected SQLite columns. Typical definitions include C(80) for text, N(12,2) for decimal values, N(10,0) for integers, L for Boolean values, and D for dates. Convert SQLite date strings to Python date objects before inserting them into a D field; use a character field instead when time or timezone data must remain visible.

An alternative two-step workflow is to export a table with the SQLite command-line shell, then import the CSV into DBF-capable desktop software:

sqlite3 source.sqlite
.headers on
.mode csv
.output customers.csv
SELECT * FROM customers;
.output stdout
.quit

CSV is only an intermediate format and does not carry SQLite types or relationships. The DBF writer still requires field names, widths, types, and an appropriate code page.

Quality and compatibility checks

• Map SQLite's dynamic values to a fixed DBF schema before conversion. Check integer ranges, decimal scale, Boolean representation, text lengths, and date formats.
• Keep character fields wide enough for the longest value. Traditional DBF character fields are commonly limited to 254 bytes, and a narrow field may truncate data or reject a record.
• Rename or map columns longer than 10 characters, columns that collide after shortening, and names containing characters rejected by the target dBASE implementation.
• Select the correct code page. cp1252 suits many Western-language applications, but older GIS software may require an OEM code page. UTF-8 support varies between DBF readers; test accented and non-Latin characters in the destination program.
• Expect possible loss of NULL distinctions, high-precision numbers, long text, timezone information, indexes, and relational structure. Preserve the original SQLite file.
• Compare source and output row counts, representative text and dates, and numeric totals after opening the DBF in the receiving application.