FoxPro
SQLite

FoxPro / DBF to SQLite Converter

Move legacy Visual FoxPro databases or standalone DBF, dBase, Clipper, and XBase files into a single SQLite database file with type-mapping review, memo-field handling, and saved jobs.

DBF to SQLite migration turns a Visual FoxPro .dbc database or a folder of free .dbf tables into one portable SQLite .db file.

The useful work is in preserving the table set around the rows: memo companions, index metadata, deleted-record flags, code pages, generated values, and date/logical fields all need a target policy before SQLite becomes the working copy.

What DBConvert does on this path: handles DBF/FoxPro → SQLite as a repeatable desktop workflow:

  • Reads Visual FoxPro .dbc databases, standalone DBF tables, dBase, Clipper, XBase, and FoxBase sources.
  • Uses companion memo files such as .fpt / .dbt and related index files when they are kept with the source folder.
  • Creates SQLite-compatible tables, maps DBF field types, and writes a single .db file.
  • Saves the job as a rerunnable session; DBSync keeps DBF and SQLite aligned while the old workflow is still active.

What it does not do: DBConvert does not rewrite FoxPro forms, reports, menus, .prg programs, or business logic into a SQLite application.

Which tool: DBConvert or DBSync?

DBConvert for DBF → SQLite

One-time migration or repeatable test loads. Use it when you need DBF/FoxPro structures, table data, type mapping, indexes, and memo fields moved into a SQLite file through a desktop wizard.

DBSync for DBF ↔ SQLite

Staged cutover or recurring exchange. Use it when the DBF source and SQLite file must keep sharing inserts, updates, and deletes until the old process is retired. Review synchronization concepts.

Need more context? Compare DBConvert and DBSync side by side →

How DBConvert handles the DBF/FoxPro → SQLite differences

DBConvert handles the table-level move in the wizard: source shape, companion files, field mapping, indexes, encoding, SQLite file creation, and validation. FoxPro application logic remains a separate rewrite track.

Source shape

DBConvert reads Visual FoxPro .dbc containers or folders of free .dbf tables. Pick the source shape at the connect step.

Memo and index files

Keep .fpt / .dbt memo companions and .cdx index files with the DBF folder so long text, General fields, and index metadata can be read with the table set.

SQLite field mapping

DBF character, numeric, logical, date, datetime, memo, and AutoInc fields are mapped to SQLite affinities before the target file is written.

Deleted rows

Decide whether DBF rows marked as deleted should be imported. For recurring jobs, keep that policy stable so SQLite refreshes do not change row counts unexpectedly.

Code pages

Legacy DOS and Windows code pages need a target encoding decision so names, addresses, and memo text do not arrive in SQLite as broken characters.

Application objects boundary

DBConvert migrates tables, views, and foreign keys. FoxPro forms, reports, menus, .prg programs, and business logic are rebuilt separately if SQLite becomes the new embedded data store.

Type mapping checkpoints

FoxPro / DBF SQLite Notes
Character (C), Varchar (V) TEXT Check code page and trailing-space policy for keys and joins.
Memo (M) TEXT Requires the matching memo companion such as .fpt or .dbt.
Numeric (N), Currency (Y) NUMERIC or scaled INTEGER Use scaled integers when exact financial arithmetic is required.
Integer (I), AutoInc INTEGER Confirm next values before new SQLite inserts begin.
Date (D), DateTime (T) TEXT, INTEGER, or REAL policy Pick one SQLite date storage convention and keep it consistent.
Logical (L) INTEGER 0 = false, 1 = true; check blank values if the DBF source uses tri-state logic.

Choosing the DBF → SQLite route

Most projects are either a portable archive, an embedded app seed, a local analytics file, or a recurring bridge while the FoxPro workflow is retired.

Route Where it fits Where it falls short
DBConvert / DBSync Visual FoxPro .dbc, folders of DBF tables, memo companions, SQLite .db output, type mapping review, saved sessions, or recurring sync. FoxPro application objects and business logic still need a separate rewrite.
Manual DBF export + SQLite import A technical user needs a few simple tables and can script CSV export plus SQLite import. You own memo handling, code pages, column mapping, indexes, retries, and validation.
Narrow DBF converter One standalone DBF table with no broader Visual FoxPro database context. Often weak on .dbc context, repeated jobs, sync, or cross-table validation.
Custom ETL SQLite is one destination in a larger embedded-app or reporting pipeline. More control, but also more code and operational ownership.

Supported versions

  • Visual FoxPro .dbc databases and standalone DBF tables
  • Free tables (DBF without .dbc container) and Memo (.fpt) files
  • SQLite 3.0 and later

Supported in this path

Source FoxPro
Target SQLite
Visual FoxPro DBF / dBase free tables Clipper / XBase DBF SQLite
FoxPro

All FoxPro Tools

Other directions and pairs
SQLite

All SQLite Tools

Migration & sync options

Reverse Conversion

SQLite to FoxPro

Using FoxPro to SQLite Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to FoxPro source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to FoxPro source database from DBConvert

FoxPro source

Select a Visual FoxPro .dbc database or a folder of free DBF tables. Keep .fpt memo and .cdx index files with the source folder so DBConvert can read the full table set.

2

Connect to SQLite destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to SQLite target database from DBConvert

SQLite target

Write a self-contained SQLite .db file at the path you pick in the wizard.

More guides for FoxPro ↔ SQLite

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options — pick tables, fields, indices, views.
  • Issue detection — the built-in checker flags integrity problems before migration starts.
  • Execute — commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI — rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3–5, software features, command-line mode, scheduler, and system requirements.

See all features