dBASE is one of the most historically important database management systems ever created for personal computers.

During the 1980s and early 1990s, before Microsoft Access, MySQL, PostgreSQL, SQL Server and modern web-based databases became commonplace, thousands of businesses built complete accounting, inventory, billing, payroll, customer-management and administrative applications around dBASE.

What made dBASE unusual was that it was not merely a place to store records.

It combined several things in one environment:

• a database engine,
• a table-file format,
• an interactive command language,
• a programming language,
• indexing,
• searching and filtering,
• forms and screen handling,
• report generation,
• application-development capabilities.

This combination meant that a single programmer could design the database, write the application and deploy an entire business system without needing a separate database server.

That was revolutionary for personal computers.

The technology became so influential that an entire family of compatible languages and database systems emerged around it. That family later became known collectively as xBase.

The influence of dBASE therefore survives in two different ways:

dBASE as a commercial product still exists, while the DBF/xBase ecosystem that dBASE created survives across many other products, programming environments and file formats.

As of 2026, dBase LLC continues to market dBASE 2019, and its official store and support site continue to provide the product and runtime components.

The Origin of dBASE: It Was Originally Called Vulcan

The story begins with American programmer C. Wayne Ratliff.

Around 1978, Ratliff developed a database program named Vulcan. The application was influenced by database concepts he had encountered while working with computer systems connected with the Jet Propulsion Laboratory environment.

One of Ratliff's objectives was surprisingly personal: he wanted a computer program that could help organize information for making football-pool predictions.

The system developed into something far more important.

Vulcan could:

• create data files,
• define fields,
• add records,
• search records,
• modify records,
• generate reports,
• and execute command sequences.

This was remarkable considering the limited computing power available at that time.

Historical accounts from dBase itself credit Wayne Ratliff with creating the language that became dBASE and describe Vulcan as its predecessor.

dBASE Was Born from Vulcan

Businessmen George Tate and Hal Lashlee recognized the commercial potential of Vulcan.

A company eventually known as Ashton-Tate obtained marketing rights to the product.

Vulcan was renamed:

dBASE II

Interestingly, there was no commercially released dBASE I.

The name "II" was largely a marketing decision intended to make the software sound mature rather than like a first-generation product. Historical accounts describe the transition from Vulcan to dBASE II in the early 1980s.

dBASE II became one of the important software applications of the CP/M era and subsequently moved into the IBM PC/MS-DOS world.

Why dBASE Became So Popular

To understand dBASE's importance, remember what personal computing looked like in the early 1980s.

There was no:

• Windows desktop as we know it,
• Microsoft Access,
• SQL Server Express,
• MySQL,
• PHP,
• .NET,
• Visual Studio,
• cloud database,
• browser-based application platform.

Businesses still needed software for:

• customers,
• invoices,
• accounting,
• inventories,
• employees,
• purchase registers,
• sales registers,
• memberships,
• schools,
• hospitals,
• warehouses,
• libraries.

dBASE gave programmers a relatively understandable way to build those systems.

Instead of writing low-level assembly or complicated compiled languages, a programmer could issue commands resembling English.

For example:

USE CUSTOMER
LIST
APPEND
REPLACE CITY WITH "DELHI"
LOCATE FOR CUSTOMER_ID = 1001
BROWSE

This was far more approachable than traditional systems programming.

dBASE Was More Than a Database

Calling dBASE simply a database can be misleading.

It was closer to an integrated database application development environment.

It contained four major layers:

1. Database Storage

Tables were typically stored as .DBF files.

2. Indexing

Separate files were used to maintain indexes so records could be found rapidly.

3. Programming Language

Developers could write programs using dBASE commands, variables, loops, conditions and procedures.

4. User Application Development

Developers could build:

• data-entry screens,
• menus,
• reports,
• labels,
• calculations,
• business logic.

This architecture helped make dBASE one of the original rapid application development environments for business software.

Understanding the DBF File

The most enduring technical contribution of dBASE may be the DBF file format.

A .DBF file is essentially a structured table.

For example:

CustomerID	Name	City	Balance
1001	ABC Traders	Delhi	12500
1002	XYZ Systems	Mumbai	8200
1003	Bison Computers	Delhi	17450

Each row is a record.

Each column is a field.

Internally, a DBF file normally contains:

1. a file header,
2. field-definition descriptors,
3. records,
4. an end-of-file marker depending on the format variant.

The header describes information such as:

• number of records,
• header size,
• record length,
• field definitions,
• data types.

This made DBF files comparatively straightforward for other developers to implement.

That simplicity is one reason DBF became a de facto data-exchange format supported by many products.

Common dBASE Field Types

Classic dBASE tables commonly supported types such as:

Character

Text values such as:

CUSTOMER_NAME
ADDRESS
CITY

Numeric

Numbers such as:

100
4250.50

Date

Traditionally represented using a compact date format.

Logical

Boolean-style values:

True / False
Yes / No

Memo

Large text was often stored separately rather than directly inside the DBF record.

Different dBASE and xBase versions expanded these types over time.

What Is a DBT File?

Long memo text could be inconvenient to place directly inside fixed-length DBF records.

dBASE therefore commonly used a separate .DBT memo file.

For example:

CUSTOMER.DBF
CUSTOMER.DBT

The DBF record contained a reference indicating where the corresponding memo text existed in the DBT file.

This separation reduced the size of individual fixed records but introduced an important maintenance concern:

The DBF and DBT files needed to remain synchronized.

Losing or corrupting the DBT file could make memo information inaccessible even if the main DBF table survived.

What Were NDX, MDX and CDX Files?

Database searching becomes slow when every record must be examined.

Indexes solve this.

Various dBASE and xBase products therefore used index files including:

• .NDX
• .MDX
• .CDX

Different implementations used different formats.

An index could be created on something such as:

CUSTOMER_ID

or:

CUSTOMER_NAME

Instead of scanning thousands of records sequentially, the engine could use the index to locate the relevant record much faster.

B-tree-family indexing techniques became fundamental to xBase database performance.

The dBASE Development Timeline

Vulcan — Around 1978–1980

Wayne Ratliff creates Vulcan.

It eventually becomes the foundation of dBASE.

dBASE II — Early 1980s

dBASE II became the breakthrough commercial release.

It became important on:

• CP/M systems,
• early IBM-compatible PCs,
• MS-DOS computers.

It helped establish Ashton-Tate as one of the major PC software companies of the period.

dBASE III — 1984

dBASE III represented a major evolution.

Historical documentation places the release of dBASE III in 1984 and describes improvements such as additional functions and broader PC capabilities.

The product became widely used for serious business software development.

dBASE III PLUS

dBASE III PLUS became particularly famous.

Many developers from the DOS era remember this version because it was used to build real commercial applications.

Improvements included stronger multi-user and networking capabilities.

Typical applications included:

• billing,
• payroll,
• inventory,
• accounting,
• membership management,
• school administration,
• hospital databases.

Many companies continued using dBASE III PLUS programs long after newer software appeared.

dBASE IV

dBASE IV was intended to modernize the platform significantly.

It introduced enhancements to the language, SQL-related functionality, application development and database handling.

However, its history was more complicated.

The product became associated with:

• higher hardware requirements,
• performance concerns on contemporary PCs,
• bugs in early releases,
• intense competition.

By that time, Fox Software's FoxBASE/FoxPro and Nantucket's Clipper were becoming extremely strong competitors.

Borland Acquires Ashton-Tate

Ashton-Tate eventually experienced serious business difficulties.

In 1991, Borland acquired Ashton-Tate.

That placed dBASE alongside Borland's other development and database technologies.

The product subsequently appeared in generations such as:

• dBASE IV,
• dBASE 5 for DOS,
• dBASE for Windows,
• Visual dBASE.

The ownership and corporate history would change again later, but the dBASE technology survived.

dBASE 5 for DOS

dBASE 5 represented one of the later important DOS generations.

It added improved development capabilities while maintaining compatibility with much of the existing xBase ecosystem.

This was important because enormous amounts of business software had already been written in dBASE-style languages.

Backward compatibility had tremendous commercial value.

Visual dBASE

As Windows replaced DOS, database developers needed graphical applications.

Visual dBASE therefore introduced a Windows-oriented development environment.

Instead of text-only screens, developers could increasingly work with:

• windows,
• buttons,
• forms,
• menus,
• mouse interaction,
• GUI controls.

This transformed dBASE from a DOS database environment into a graphical Windows development platform.

dBASE Plus

Later generations were released under the dBASE Plus name.

For example:

• dBASE PLUS 8
• dBASE PLUS 9
• dBASE PLUS 10
• dBASE PLUS 11
• dBASE PLUS 12

dBASE Plus evolved beyond classic DBF-only programming and incorporated connections to modern database technologies.

dBase described dBASE PLUS 12, released in 2018, as a Windows low-code/no-code development environment and added features such as integrated JSON support.

dBASE 2019

The current version prominently marketed by dBase LLC is dBASE 2019.

The official dBase website continues to market dBASE 2019, while the company's update page lists dBASE 2019.2 and its runtime components.

Its improvements have included areas such as:

• IDE enhancements,
• compiler improvements,
• editor enhancements,
• component improvements,
• ADO support,
• Windows-oriented application development.

Therefore, one important misconception should be corrected:

dBASE is not merely a dead DOS database. A commercial dBASE product still exists.

However, its market position is very different from its dominance during the 1980s.

So Which Modern Database Did dBASE Become?

This is one of the most interesting questions.

The answer is:

dBASE did not simply turn into one single modern database.

It evolved into an entire family of compatible technologies called xBase.

The lineage can be visualized approximately as:

Vulcan
   |
   v
dBASE II
   |
   v
dBASE III
   |
   +------------------------------+
   |                              |
   v                              v
dBASE III Plus               xBase-compatible products
   |                              |
   v                      +-------+---------+
dBASE IV                   |       |        |
   |                    FoxBASE  Clipper  others
   v                       |       |
dBASE 5                 FoxPro   Harbour
   |                       |
   v                       v
Visual dBASE          Visual FoxPro
   |
   v
dBASE Plus
   |
   v
dBASE 2019

So dBASE's influence survives through multiple branches.

What Is xBase?

xBase is a general term for programming languages, database engines and development environments derived from or compatible with the dBASE language and DBF database model.

Examples include:

• dBASE,
• FoxBASE,
• FoxPro,
• Visual FoxPro,
• Clipper,
• CA-Clipper,
• Harbour,
• xHarbour,
• various DBF libraries.

Think of dBASE as the original influential ancestor.

xBase is the wider family that developed around it.

dBASE and FoxBASE

One of the most important dBASE-compatible products was FoxBASE.

Fox Software designed FoxBASE to be highly compatible with dBASE while emphasizing performance.

This was critically important because developers could often move existing applications or programming knowledge from dBASE to FoxBASE without starting again.

FoxBASE eventually evolved into:

FoxPro

and later:

Microsoft Visual FoxPro

FoxPro

FoxPro became one of the strongest competitors and successors in the xBase ecosystem.

Its reputation was built partly around extremely fast indexing and searching.

Developers appreciated FoxPro for:

• powerful DBF support,
• high-speed indexes,
• sophisticated querying,
• programming capabilities,
• application development.

FoxPro eventually became a major database development platform in its own right.

Microsoft Purchases Fox Software

Microsoft acquired Fox Software in 1992.

FoxPro subsequently became a Microsoft product.

Later it evolved into:

Visual FoxPro

Visual FoxPro combined:

• xBase programming,
• object-oriented development,
• forms,
• reports,
• classes,
• database containers,
• SQL-style querying,
• COM integration,
• Windows application development.

It became one of the most powerful descendants of the original dBASE/xBase architecture.

Visual FoxPro: A Major Descendant of the dBASE World

Visual FoxPro was much more advanced than early dBASE.

Its architecture supported concepts such as:

• object-oriented programming,
• classes,
• inheritance,
• event-driven forms,
• local DBF tables,
• database containers,
• SQL queries,
• remote SQL databases,
• ActiveX,
• COM automation,
• client/server development.

Yet a developer familiar with classic xBase would still recognize commands and concepts originating from dBASE.

For example:

USE CUSTOMER
BROWSE
LOCATE
SEEK
REPLACE
APPEND BLANK

That programming heritage remained clearly visible.

Why Did Microsoft Stop Visual FoxPro?

Visual FoxPro 9 became the final major version.

Microsoft's official lifecycle information shows:

• Visual FoxPro 9 start date: December 22, 2004
• mainstream support ended: January 13, 2010
• extended support ended: January 14, 2015.

Microsoft did not release Visual FoxPro 10.

Even so, numerous legacy Visual FoxPro systems remain operational because compiled VFP applications can continue running on later Windows installations under suitable conditions.

Was FoxPro Simply a New Version of dBASE?

No.

This distinction is important.

FoxPro was not literally dBASE renamed.

It was a separate implementation developed to be compatible with much of the dBASE language and file ecosystem.

A useful analogy is:

dBASE = original influential platform

FoxBASE/FoxPro = compatible competing implementation

Visual FoxPro = Microsoft's advanced descendant of FoxBASE/FoxPro

All belong broadly to the xBase family.

dBASE and Clipper

Another hugely important branch was:

Clipper

Nantucket's Clipper allowed developers to take dBASE-style source code and compile it into standalone DOS executables.

This addressed one of the limitations of traditional interpreted database development.

Instead of requiring users to run everything inside the dBASE environment, developers could distribute compiled applications.

For example:

CUSTOMER.EXE
ACCOUNT.EXE
INVENTORY.EXE

This made Clipper extremely popular among professional software developers.

Why Was Clipper So Important?

Imagine an accounting software developer in the late 1980s.

Using dBASE directly might mean requiring the database environment on every customer's computer.

With Clipper, the developer could compile the program and distribute an executable.

Benefits included:

• easier deployment,
• better source-code protection,
• potentially faster execution,
• professional software distribution,
• independence from the interactive dBASE environment.

Many commercial DOS programs were therefore built using Clipper and DBF files.

CA-Clipper

Clipper was later associated with Computer Associates and became commonly known as:

CA-Clipper

The final major generation, particularly Clipper 5.x, remained widely used for business applications for many years.

Harbour: The Modern Descendant of Clipper/xBase

One of the most important answers to the question "Where is dBASE technology today?" is:

Harbour

Harbour is an open-source implementation of an xBase language heavily compatible with Clipper-style programming.

It allows developers to use familiar xBase syntax while targeting modern operating systems and compilers.

Related projects include:

• Harbour
• xHarbour

Thus, applications inspired by the original dBASE programming model can still be developed today using modern toolchains.

From dBASE to Harbour: The Programming Lineage

A simplified lineage is:

dBASE
   |
   v
xBase language
   |
   +----------------+
   |                |
FoxBASE/FoxPro    Clipper
   |                |
Visual FoxPro      CA-Clipper
                    |
                    v
                  Harbour
                    |
                    v
                 xHarbour

This is one of the strongest examples of how a programming language ecosystem can survive long after its original commercial dominance disappears.

DBF Files Are Still Used Today

Even more significant than the programming language is the survival of the .DBF format.

DBF tables can still be opened or processed by many tools, programming libraries and data-conversion applications.

Common environments may include support through:

• database utilities,
• spreadsheet import/export,
• GIS software,
• Python libraries,
• data-conversion tools,
• ODBC drivers,
• legacy accounting applications,
• ERP applications,
• custom Windows applications.

The format has survived because it is relatively simple, well understood and enormously widespread in historical systems.

One Major Modern Use of DBF: GIS Shapefiles

One of the most surprising places where dBASE technology still survives is geographic information systems.

The widely used ESRI Shapefile format consists of several related files.

Typically:

ROADS.SHP
ROADS.SHX
ROADS.DBF

The .SHP file contains geometry.

The .SHX file contains indexing information.

The .DBF file stores the attributes.

ESRI's shapefile specification explicitly defines the .dbf file as the dBASE table containing feature attributes.

This means software architecture originating in the early personal-computer database era remains embedded in an important geospatial data format decades later.

Example of dBASE Inside GIS

Imagine a map containing roads.

The geometry might exist in:

roads.shp

while the related data might appear conceptually as:

ROAD_ID | ROAD_NAME | TYPE | LENGTH
1       | Main Road | HWY  | 5.6
2       | Park Lane | RD   | 1.2

Those attributes may be stored in:

roads.dbf

The record order corresponds with the shapes.

Thus a modern mapping system can still contain a DBF table descended from the dBASE world.

Why DBF Survived for More Than Four Decades

Several technical reasons explain its extraordinary lifespan.

1. Simple Structure

The format is relatively straightforward.

2. Self-Describing Fields

The file header contains definitions for columns.

3. No Database Server Required

A DBF file can simply exist in a directory.

There is no mandatory server service.

4. Easy Backup

Historically, users could back up:

*.DBF
*.DBT
*.NDX
*.MDX

by copying files.

5. Portable

DBF implementations existed across many operating systems and products.

6. Huge Installed Base

Millions of existing applications created a powerful compatibility incentive.

7. Easy Integration

Developers wrote drivers and libraries for DBF relatively easily.

Why Old dBASE Applications Can Still Run

Many users are surprised when a database application written decades ago continues functioning.

Several factors explain this.

Stable File Format

The underlying DBF data structure did not require a constantly running server.

Native or Compiled Applications

Some dBASE-family applications were compiled into ordinary executables.

Minimal External Dependencies

Old programs might only require:

PROGRAM.EXE
CUSTOMER.DBF
CUSTOMER.DBT
CUSTOMER.MDX

There might be:

• no web browser,
• no cloud API,
• no JavaScript framework,
• no online activation server,
• no continuously changing web service.

Long-Lived Win32 Compatibility

Windows has historically maintained substantial compatibility with Win32 applications.

Consequently, many old 32-bit database applications continued working long after their development environments disappeared.

But Why Do Some DOS dBASE Applications Not Run on Modern Windows?

Modern 64-bit Windows versions generally cannot directly execute traditional 16-bit DOS applications.

Therefore an old DOS dBASE or Clipper application may require:

• DOSBox,
• DOSBox-X,
• vDos,
• virtual machine,
• older Windows environment,
• application migration.

The DBF data itself, however, may remain perfectly readable.

This distinction is critical:

The application executable may become incompatible while the database files remain usable.

dBASE Versus Modern SQL Databases

Classic dBASE fundamentally differs from client/server relational database systems such as:

• Microsoft SQL Server,
• MySQL,
• PostgreSQL,
• Oracle,
• MariaDB.

A classic DBF application commonly accesses files directly.

Example:

\\SERVER\DATA\CUSTOMER.DBF

A SQL architecture normally looks more like:

Application
    |
    v
Database Server
    |
    v
Database Files

The application sends queries to the database server.

File-Server Model vs Client/Server Model

Traditional DBF Architecture

PC 1 --------\
PC 2 ---------> Shared DBF Files
PC 3 --------/

Each workstation may directly read records from the shared file.

SQL Server Architecture

PC 1 --------\
PC 2 ---------> SQL Server ----> Database
PC 3 --------/

The server handles:

• queries,
• transactions,
• locking,
• caching,
• security,
• concurrency.

For large multi-user environments, client/server architecture is generally more robust.

dBASE Was Not a Pure Modern Relational Database

dBASE is frequently described historically as a relational database system, but its original architecture differs significantly from contemporary relational database management systems.

Classic DBF environments often relied heavily on:

• individual tables,
• indexes,
• procedural relationships,
• application logic.

Modern SQL systems tend to provide richer database-engine enforcement for:

• primary keys,
• foreign keys,
• transactions,
• referential integrity,
• constraints,
• views,
• triggers,
• stored procedures.

Later dBASE-family products became much more sophisticated, but classic dBASE should be understood in the context of its era.

The Famous dBASE Programming Style

One reason dBASE influenced so many programmers was its readable language.

Consider a simplified example:

USE CUSTOMER
SET INDEX TO CUSTOMER

SEEK "BISON"

IF FOUND()
   ? CUSTOMER_NAME
   ? BALANCE
ENDIF

Or:

DO WHILE .NOT. EOF()
   IF BALANCE > 10000
      ? CUSTOMER_NAME, BALANCE
   ENDIF

   SKIP
ENDDO

A non-specialist could often understand roughly what the code was doing.

This made application development accessible to business programmers.

Important Classic dBASE Commands

USE

Opens a database table.

USE CUSTOMER

BROWSE

Displays records interactively.

BROWSE

APPEND

Adds records.

APPEND

APPEND BLANK

Creates an empty record.

REPLACE

Changes field values.

REPLACE CITY WITH "NEW DELHI"

DELETE

Marks a record for deletion.

PACK

Physically removes records that were previously marked deleted.

LOCATE

Finds a record matching a condition.

SEEK

Uses an index to locate a key rapidly.

SKIP

Moves between records.

GO TOP

Moves to the first logical record.

GO BOTTOM

Moves to the last record.

ZAP

Removes all records from the current table.

This is an extremely destructive command and must be used carefully.

An Interesting dBASE Concept: Deleted Records Were Often Not Immediately Removed

When a user issued:

DELETE

the record could simply be marked for deletion.

It remained physically present.

Later:

PACK

could permanently rebuild the table without those deleted records.

This design had advantages in the era of floppy disks and relatively slow storage.

It also meant that deleted information could sometimes remain recoverable before packing.

Record Locking and Multi-User Applications

When networks became common, dBASE-family products had to handle multiple people accessing the same database.

Example:

User A -> CUSTOMER.DBF
User B -> CUSTOMER.DBF
User C -> CUSTOMER.DBF

If User A edits customer 1001 while User B edits the same record, corruption or conflicting changes could occur without appropriate locking.

xBase applications therefore implemented techniques such as:

• record locking,
• file locking,
• retry loops,
• shared mode,
• exclusive mode.

For example:

RLOCK()

might be used in compatible xBase dialects to obtain a record lock before editing.

Major Weakness of DBF Network Applications

Traditional file-server databases can generate substantial network traffic.

Suppose a table contains:

1,000,000 records

and the workstation must search without a suitable index.

Large amounts of information may need to travel across the LAN.

A client/server database could instead process:

SELECT *
FROM Customers
WHERE CustomerID = 1001;

on the server and return only the matching information.

That architectural difference was one factor that encouraged businesses to migrate from DBF systems toward SQL databases.

DBF Corruption

Because clients can access DBF files directly, problems can arise from:

• sudden power failure,
• network disconnection,
• workstation crash,
• damaged index files,
• improper application termination,
• concurrent writes,
• storage failure.

A frequently encountered problem in old systems was:

Database appears corrupt

when the actual problem involved a damaged index.

Sometimes rebuilding:

.NDX
.MDX
.CDX

could restore operation even when the DBF table itself was intact.

Why Modern SQL Databases Replaced dBASE in Many New Applications

Several technical trends worked against classic DBF architectures.

1. Client/Server Computing

SQL Server and Oracle allowed centralized processing.

2. Transactions

Modern databases provide strong transactional guarantees.

3. Security

Database permissions could be enforced centrally.

4. Larger Databases

Modern DBMS engines handle massive datasets more effectively.

5. Web Applications

Web servers work naturally with server-based databases.

6. Unicode

Modern systems offer superior multilingual support.

7. Cloud Computing

Cloud database platforms require architectures very different from classic local DBF files.

8. Concurrency

SQL engines generally handle hundreds or thousands of simultaneous operations better.

Limitations of the Classic DBF Format

Different DBF generations have different capabilities, so exact limits vary.

Nevertheless, older DBF variants have historically faced limitations involving:

• field-name length,
• character encoding,
• Unicode,
• maximum record size,
• maximum field counts,
• date/time representation,
• memo-file dependency,
• lack of strong transactional integrity,
• weak built-in relational constraints.

ESRI specifically warns of limitations in the dBASE format used by shapefiles, including restrictions involving field names, null handling and character representation.

dBASE and Unicode

Classic DBF formats were designed decades before Unicode became the universal standard.

Consequently, international text can become difficult when code pages differ.

For example:

English
Hindi
Punjabi
Chinese
Arabic
Japanese

require much better character-set support than early PC databases were designed to provide.

Modern database engines commonly use Unicode data types natively.

dBASE and SQL

Another common misconception is:

"dBASE was replaced by SQL."

This is only partially correct.

SQL is primarily a database query language, while products such as SQL Server, PostgreSQL and MySQL are database management systems.

dBASE offered its own procedural command language.

Over time, xBase products also incorporated SQL-style capabilities.

Modern dBASE products can also interact with external databases rather than being limited exclusively to DBF.

Modern dBASE and External Databases

Current generations of dBASE can work beyond traditional DBF files.

Technologies such as:

• ADO,
• ODBC,
• database drivers,

allow applications to connect to external database servers.

Therefore a modern dBASE application could conceptually use:

dBASE application
        |
        +--> DBF
        |
        +--> SQL Server
        |
        +--> MySQL
        |
        +--> PostgreSQL
        |
        +--> other ODBC/ADO data sources

This demonstrates how dBASE evolved from a standalone PC database toward a broader application-development environment.

The Borland Database Engine

Windows-era Borland products frequently used the Borland Database Engine, commonly called BDE.

The BDE acted as a database-access layer for various Borland applications.

It supported formats and technologies such as:

• dBASE tables,
• Paradox tables,
• SQL databases through drivers.

Applications built using older versions of:

• Delphi,
• C++Builder,
• dBASE,
• Paradox,

may still contain dependencies on the BDE.

Modern development normally favors more recent database libraries.

Is DBF a Database or a File Format?

Technically:

DBF is primarily a database table file format.

A complete dBASE application may consist of several files.

For example:

CUSTOMER.DBF
CUSTOMER.DBT
CUSTOMER.MDX
CUSTOMER.PRG
CUSTOMER.FRM
REPORT.REP

The .DBF contains tabular data.

The rest may contain:

• memo information,
• indexes,
• application code,
• forms,
• reports.

So when someone says:

"My database is DBF"

they usually mean that their application stores data in dBASE-compatible DBF tables.

Why DBF Files Are Easy to Move

Compare two database architectures.

A SQL Server database might depend on:

• SQL Server service,
• database configuration,
• users,
• permissions,
• instance settings,
• MDF/LDF files,
• authentication,
• server version.

A DBF database could often be copied simply as:

DATA\
    CUSTOMER.DBF
    SALES.DBF
    STOCK.DBF
    CUSTOMER.MDX
    SALES.MDX

This portability was tremendously useful for small businesses.

Why DBF Was Perfect for the Early PC Era

Typical PCs in the 1980s might have had:

• extremely limited RAM,
• floppy disks,
• small hard disks,
• low CPU speeds,
• no networking,
• DOS.

A database engine therefore had to be:

• compact,
• efficient,
• local,
• file-based,
• simple.

dBASE was designed for exactly that world.

Its architecture therefore made excellent sense at the time.

Was dBASE the Microsoft Access of Its Time?

In some ways, yes.

Both products allowed users to combine:

• tables,
• queries,
• forms,
• reports,
• application logic.

But there are important architectural and historical differences.

dBASE became a programming-language ecosystem whose syntax was copied and extended by numerous vendors.

Access developed around Microsoft technologies including Jet and later ACE database engines and VBA.

A useful comparison is:

Feature	dBASE	Microsoft Access
Main historical period	1980s onward	1990s onward
Core file	DBF	MDB/ACCDB
Programming	xBase	VBA
Forms	Yes	Yes
Reports	Yes	Yes
Indexing	Yes	Yes
Multi-user	Yes, with limitations depending on version	Yes
SQL support	Later generations	Strong
Ecosystem descendants	Huge xBase family	Primarily Microsoft ecosystem

dBASE Versus FoxPro

Feature	dBASE	FoxPro
Origin	Wayne Ratliff / Ashton-Tate	Fox Software
Compatibility standard	Original influence	dBASE-compatible
File format	DBF	DBF
Programming language	dBASE/xBase	FoxPro/xBase
Indexing	NDX/MDX etc.	Highly optimized index technologies
Windows evolution	Visual dBASE	Visual FoxPro
Current commercial status	dBASE still marketed	Visual FoxPro discontinued

dBASE Versus Clipper

dBASE	Clipper
Interactive DBMS/development system	Primarily compiler/development environment
Could execute commands interactively	Compiled source into executables
Created DBF-based applications	Used compatible DBF-based architecture
Commercial application development	Extremely popular for commercial DOS apps

dBASE Versus Harbour

dBASE	Harbour
Commercial product lineage	Open-source project
Original xBase influence	Modern xBase implementation
Historical DBF environment	Can support modern platforms
Proprietary development system	Open development ecosystem

How dBASE Influenced Low-Code Development

Today low-code platforms are promoted as a modern concept.

Yet dBASE provided many comparable productivity principles decades earlier.

A developer could quickly:

• create a table,
• browse records,
• build forms,
• write business logic,
• print reports,
• generate an application.

You did not need to manually implement:

• file parsing,
• record storage,
• database indexing,
• basic navigation,
• report pagination.

That dramatically reduced development effort.

dBase itself now describes dBASE Plus generations in low-code/no-code terms.

Why Businesses Loved dBASE

For a small company in the 1980s, hiring a mainframe software-development team was unrealistic.

But one capable dBASE programmer could create:

Customer Master
Supplier Master
Item Master
Sales Entry
Purchase Entry
Stock Ledger
Outstanding Report
Ageing Report
Sales Analysis
Label Printing

on an ordinary PC.

That democratized business software.

Why Developers Loved dBASE

The language gave immediate feedback.

You could type:

USE CUSTOMER
BROWSE

and immediately see the data.

Then:

LIST FOR CITY = "DELHI"

could retrieve matching records.

That interactive development cycle made experimentation very fast.

Why dBASE Skills Became Transferable

Once programmers learned:

USE
SKIP
SEEK
LOCATE
REPLACE
APPEND
DELETE
PACK
INDEX

they could adapt relatively easily to:

• FoxBASE,
• FoxPro,
• Clipper,
• Visual FoxPro,
• Harbour.

This created an enormous pool of xBase developers.

Where Is dBASE Technology Still Found Today?

The dBASE legacy survives in at least seven major forms.

1. Modern dBASE

dBase LLC continues to market dBASE 2019.

2. Legacy DBF Applications

Thousands of organizations still operate old:

• accounting systems,
• inventory programs,
• manufacturing applications,
• payroll programs,
• membership databases.

3. Visual FoxPro Systems

Many VFP applications remain operational even though Microsoft support has ended.

4. Harbour/xHarbour Applications

Modern xBase development continues through open-source implementations.

5. GIS Shapefiles

DBF remains an essential component of the shapefile standard.

6. Data Exchange

DBF remains useful for transferring tabular data between legacy environments.

7. Database Conversion

Numerous migration utilities still understand DBF because so much historical data exists in it.

Is dBASE Still Used as the Database Behind Modern Applications?

Yes, but much less commonly for newly designed large-scale enterprise systems.

Today DBF-based applications are most frequently found where:

• an established application already works,
• replacing it is expensive,
• datasets are relatively small,
• only a limited number of users access it,
• the system is isolated from the internet,
• compatibility with old software is required.

For new web or cloud applications, developers more commonly choose databases such as:

• PostgreSQL,
• MySQL,
• MariaDB,
• SQL Server,
• SQLite.

Is SQLite the Modern Version of dBASE?

No.

People sometimes make this comparison because both can operate without a dedicated database server.

However:

dBASE/DBF ≠ SQLite

SQLite is a modern embedded SQL relational database engine.

A SQLite database typically uses a single integrated database file and supports:

• SQL,
• transactions,
• indexes,
• tables,
• constraints,
• ACID semantics.

Classic DBF architectures use individual table files and external indexes/memo files.

Conceptually, however, SQLite fills some modern use cases similar to those once served by dBASE: lightweight local database applications without a separate server.

Is Microsoft Access the Successor to dBASE?

Not technically.

Microsoft Access did not evolve from dBASE.

However, commercially it occupied part of the desktop database market that dBASE had once dominated.

So it is reasonable to say that Access became one of the products that replaced dBASE in many organizations, but it is not a direct descendant.

Is Visual FoxPro the Successor to dBASE?

Again, not exactly.

Visual FoxPro descended from FoxBASE/FoxPro, which was designed around dBASE compatibility.

Therefore Visual FoxPro is better described as:

one of the most important descendants of the xBase ecosystem created by dBASE.

Which Database Is Closest to dBASE Today?

The answer depends on what "closest" means.

Same product lineage

dBASE 2019

Same language family

Harbour / xHarbour

Famous historical compatible descendant

Visual FoxPro

Same DBF-style storage ecosystem

DBF-compatible libraries and applications

Similar modern serverless concept

SQLite, although technically unrelated.

Modern enterprise replacement

SQL Server, PostgreSQL, MySQL/MariaDB, depending on the application.

Should an Existing dBASE Application Be Replaced?

Not automatically.

If a 25-year-old system:

• works correctly,
• is stable,
• has reliable backups,
• serves only a few users,
• is isolated from internet exposure,
• and meets business requirements,

then migration should be based on business need rather than age alone.

However, migration deserves serious consideration if you face:

• failing hardware,
• unsupported runtime dependencies,
• poor security,
• corrupted tables,
• remote access requirements,
• large data volumes,
• simultaneous users,
• web integration,
• mobile access,
• APIs,
• Unicode requirements,
• unavailable source code,
• disappearing developer expertise.

Migrating DBF Data to SQL

A common modernization architecture is:

CUSTOMER.DBF
SALES.DBF
PURCHASE.DBF
STOCK.DBF
        |
        v
Data Conversion
        |
        v
SQL Database

Possible targets include:

SQL Server
PostgreSQL
MySQL
MariaDB
SQLite

Migration generally requires more than copying rows.

You must examine:

• field types,
• date formats,
• numeric precision,
• deleted records,
• character encoding,
• memo fields,
• indexes,
• duplicate keys,
• relationships.

Example DBF-to-SQL Mapping

A DBF structure might be:

CUSTOMER.DBF

CUSTCODE   Character(10)
NAME       Character(50)
BALANCE    Numeric(12,2)
ACTIVE     Logical
DOB        Date

A SQL version might become:

CREATE TABLE Customers
(
    CustomerCode VARCHAR(10) PRIMARY KEY,
    Name VARCHAR(50),
    Balance DECIMAL(12,2),
    Active BOOLEAN,
    DateOfBirth DATE
);

The SQL design can then introduce stronger controls such as:

• primary keys,
• foreign keys,
• unique indexes,
• constraints.

Why Blind DBF-to-SQL Conversion Can Fail

Old xBase software often stored business relationships in application code rather than database constraints.

For example:

CUSTOMER.DBF
SALES.DBF
PAYMENT.DBF

might all contain:

CUSTCODE

but no actual database-level foreign key exists.

The programmer knew that:

SALES.CUSTCODE

referred to:

CUSTOMER.CUSTCODE

A migration project therefore needs to reverse-engineer the application's business rules.

Legacy xBase Systems Can Be Surprisingly Fast

A properly indexed DBF application can be extremely fast for small and medium datasets.

For example:

SEEK CustomerCode

through a well-built local index can return a record almost instantly.

This explains why some users say:

"Our old FoxPro or dBASE application feels faster than modern software."

The comparison may indeed feel true because the old application often has:

• no browser engine,
• no HTTP requests,
• no cloud round-trip,
• no heavy framework,
• very small executable code,
• locally indexed data.

Its workload is extremely direct.

Why Modern Software Can Feel Slower

A modern web application might involve:

Browser
   |
JavaScript framework
   |
HTTPS
   |
Web server
   |
Application framework
   |
ORM
   |
Database server
   |
Response
   |
JSON
   |
Browser rendering

An old DBF application might effectively do:

Application
   |
DBF + index

This does not mean DBF is technically superior overall.

It means that a lightweight architecture can provide excellent perceived performance for simple local workloads.

The Historical Importance of dBASE

dBASE deserves recognition alongside software such as:

• Lotus 1-2-3,
• WordStar,
• WordPerfect,
• VisiCalc,
• Lotus Organizer,
• FoxPro,
• Paradox.

These products helped define the early personal-computing industry.

dBASE's particular contribution was demonstrating that serious business databases could run on relatively inexpensive personal computers.

dBASE Changed Software Development

Before systems such as dBASE, database programming was often associated with:

• mainframes,
• minicomputers,
• expensive corporate IT departments.

dBASE moved database development onto the desk of ordinary business programmers.

That change helped create the market for:

• PC database consultants,
• independent software vendors,
• accounting-software developers,
• custom MIS applications,
• vertical-market software.

The dBASE Family Tree

A simplified technical family tree is:

                     Wayne Ratliff
                          |
                       Vulcan
                          |
                       dBASE II
                          |
                       dBASE III
                          |
            +-------------+--------------+
            |                            |
        dBASE lineage                xBase ecosystem
            |                            |
        dBASE III+           +-----------+-----------+
            |                |                       |
        dBASE IV          FoxBASE                 Clipper
            |                |                       |
        dBASE 5           FoxPro                 CA-Clipper
            |                |                       |
       Visual dBASE     Visual FoxPro             Harbour
            |                                        |
        dBASE Plus                                xHarbour
            |
        dBASE 2019

The actual historical ecosystem is more complicated, but this diagram captures the principal relationships.

What Does "xBase" Actually Mean?

The "x" in xBase essentially represents the many implementations derived from the dBASE model.

Instead of saying:

dBASE + FoxBASE + FoxPro + Clipper + Harbour + others

developers can broadly refer to them as:

xBase

There is no single vendor controlling all xBase implementations.

It describes a family.

Why dBASE Is Important to Software History

dBASE contributed at least five major ideas to personal computing.

1. Database Management for Ordinary PCs

It made databases accessible outside large corporate computer centers.

2. Integrated Application Development

Programming and data management existed in one environment.

3. Human-Readable Commands

Its English-like syntax lowered the learning barrier.

4. DBF Standardization

Its file format became widely adopted.

5. xBase Ecosystem

Its language inspired decades of compatible products.

Is dBASE Dead?

No — but its role has changed dramatically.

A better description is:

dBASE is a living legacy technology.

Its original dominance is over.

But:

• dBASE software is still marketed,
• DBF files are still used,
• GIS shapefiles still rely on DBF,
• Visual FoxPro applications still exist,
• Harbour/xHarbour continue xBase development,
• migration tools continue supporting DBF.

That is an extraordinary lifespan for a technology originating in the late 1970s.

dBASE Timeline at a Glance

Period	Development
1978	Wayne Ratliff develops Vulcan
Early 1980s	Vulcan becomes dBASE II
1984	dBASE III appears
Mid-1980s	dBASE III Plus becomes widely used
Late 1980s	dBASE IV
1991	Borland acquires Ashton-Tate
1990s	dBASE 5 and Windows-oriented versions
1990s	Visual dBASE
Later	dBASE Plus generations
2018	dBASE Plus 12 announced
2019 onward	dBASE 2019 generation
Present	dBASE/DBF/xBase ecosystem continues

FAQ

1. What is dBASE?

dBASE is a database management and application-development system originally derived from Wayne Ratliff's Vulcan database. It became one of the most influential personal-computer database platforms.

2. Who invented dBASE?

The core technology was created by C. Wayne Ratliff, originally under the name Vulcan.

3. Who marketed dBASE?

The product became famous through Ashton-Tate.

4. Was there a dBASE I?

No widely marketed dBASE I preceded dBASE II. The "II" designation was primarily a marketing choice.

5. What operating system did early dBASE use?

Early generations ran on systems such as CP/M and later MS-DOS.

6. What is a DBF file?

DBF is the primary table-file format associated with dBASE and many xBase systems.

7. Is DBF still used today?

Yes. DBF is still supported by various legacy applications, database utilities, programming libraries and GIS technologies.

8. Is dBASE still available?

Yes. dBase LLC continues to market dBASE 2019 on its official website as of 2026.

9. Is Visual FoxPro the same as dBASE?

No. Visual FoxPro descended from FoxBASE/FoxPro, which belonged to the dBASE-compatible xBase ecosystem.

10. Is FoxPro based on dBASE?

FoxBASE and FoxPro were designed around strong compatibility with dBASE-style language and DBF data.

11. What is xBase?

xBase is the collective family of programming languages and database systems derived from or compatible with dBASE concepts.

12. Which products belong to xBase?

Examples include dBASE, FoxBASE, FoxPro, Visual FoxPro, Clipper, Harbour and xHarbour.

13. What is Clipper?

Clipper is an xBase development language/compiler that became extremely popular for creating standalone DOS business applications using DBF data.

14. What is Harbour?

Harbour is a modern open-source xBase programming environment strongly influenced by the Clipper language.

15. What is xHarbour?

xHarbour is another project within the modern xBase ecosystem.

16. What is an NDX file?

NDX is one type of index file used by dBASE-style systems.

17. What is an MDX file?

MDX is another dBASE index format capable of storing multiple index tags depending on the implementation.

18. What is a CDX file?

CDX is commonly associated with FoxPro-compatible compound indexes.

19. What is a DBT file?

A DBT file is traditionally used to store memo or large-text data referenced from a DBF table.

20. Can DBF data be converted to SQL Server?

Yes. DBF tables can be migrated to SQL Server, but field types, indexes, memo files, encoding and application relationships should be reviewed carefully.

21. Can DBF be converted to MySQL?

Yes.

22. Can DBF be converted to PostgreSQL?

Yes.

23. Can DBF be converted to SQLite?

Yes.

24. Is SQLite a modern version of dBASE?

No. SQLite is technically unrelated, although both can support serverless/local database applications.

25. Is Microsoft Access based on dBASE?

No. Access is a separate Microsoft technology, although it eventually occupied much of the desktop-database market once associated with products such as dBASE.

26. Why were dBASE programs so fast?

They often used compact native code, local data files and efficient indexes without the overhead of browsers, web APIs or network database servers.

27. Why are some old dBASE applications still running?

Because their file formats and dependencies can be remarkably stable, particularly when they are compiled Windows applications or run through suitable compatibility environments.

28. Can DOS dBASE applications run on Windows 11?

Traditional DOS applications generally require an emulation or virtualization environment such as DOSBox, DOSBox-X, vDos or a compatible virtual machine.

29. Can Windows dBASE applications run on Windows 11?

Some can, depending on architecture, runtime components, dependencies and whether the application is 32-bit or 16-bit.

30. Does Visual FoxPro still work?

Many Visual FoxPro applications continue to operate, although Microsoft ended extended support for Visual FoxPro 9 in January 2015.

31. Why did Microsoft discontinue Visual FoxPro?

Microsoft decided not to develop a Visual FoxPro 10 and shifted its development ecosystem toward other technologies including .NET and SQL Server.

32. Does GIS still use dBASE technology?

Yes. The ESRI Shapefile standard uses a .DBF file for attribute information.

33. Is DBF a good choice for a new enterprise application?

Usually not. Modern client/server databases provide better transaction handling, security, Unicode, concurrency and scalability.

34. Should every legacy DBF application be replaced?

No. If a system is secure, reliable and meets business requirements, migration should be based on risk and business need rather than age alone.

35. What are the biggest reasons to migrate from DBF?

Common reasons include security requirements, remote users, cloud integration, large datasets, concurrency, web/mobile integration and lack of maintainable source code.

36. Can a modern web application read DBF?

Yes. Programming libraries exist in various languages for reading DBF files, although converting the data to a modern database may be preferable for active web systems.

37. Is dBASE relational?

It provided relational-style data management, but classic dBASE lacked many database-engine constraints associated with modern relational DBMS platforms.

38. Did dBASE support programming?

Yes. Programming was one of its defining strengths.

39. What language did dBASE use?

It used the dBASE command/programming language that became the basis of the broader xBase language family.

40. What was the most famous dBASE version?

dBASE III and dBASE III Plus are among the most historically famous versions.

41. Why did FoxPro become popular?

Its compatibility, performance and powerful indexing made it highly attractive to dBASE developers.

42. Why did Clipper become popular?

It allowed xBase developers to compile applications into distributable executables.

43. What replaced dBASE?

No single product replaced it. Microsoft Access, FoxPro, SQL Server, Oracle, MySQL, PostgreSQL and many other systems absorbed different parts of its market.

44. Which technology is dBASE closest to today?

For direct lineage, modern dBASE. For xBase programming, Harbour/xHarbour. For historical compatibility, FoxPro/Visual FoxPro and Clipper.

45. Is the dBASE file format documented?

Yes, numerous specifications and implementations exist, and the DBF structure is widely understood.

46. Why has DBF survived so long?

Its simplicity, massive installed base, portability and broad software support gave it extraordinary longevity.

47. Is dBASE historically important?

Extremely. It helped establish database-driven business applications as a mainstream use of personal computers.

48. Did dBASE contribute to low-code development?

Conceptually, yes. It allowed users to combine database creation, forms, reporting and application logic with relatively little low-level programming.

49. Is Harbour a possible migration path for Clipper applications?

Yes. Harbour is frequently considered when modernizing or recompiling Clipper/xBase source code, although application-specific compatibility must be tested.

50. What is the biggest legacy of dBASE?

Its greatest legacy is not merely one software product. It is the combination of DBF as a long-lived data format, xBase as a programming family, and the idea that ordinary PC developers could rapidly build complete database-driven business applications.

Conclusion

dBASE occupies a unique position in computing history.

It began with Wayne Ratliff's Vulcan project in the late 1970s, was commercialized as dBASE II, became hugely successful through dBASE III and dBASE III Plus, evolved through dBASE IV, dBASE 5, Visual dBASE, dBASE Plus and dBASE 2019, and simultaneously inspired an enormous ecosystem of compatible technologies.

That ecosystem produced:

FoxBASE
FoxPro
Visual FoxPro
Clipper
CA-Clipper
Harbour
xHarbour

while the .DBF file became a long-lived industry format.

So if we ask:

"What database did dBASE eventually become?"

the most accurate answer is:

It did not become one database. dBASE became the foundation of the xBase ecosystem. Its direct commercial descendant is modern dBASE, while its technological descendants include FoxPro, Visual FoxPro, Clipper, Harbour and xHarbour. Its DBF file format also survives independently in legacy applications, conversion tools and even modern GIS shapefiles.

Very few personal-computer technologies created in the late 1970s can still be found in actively used data formats and applications more than four decades later.

That longevity makes dBASE far more than an obsolete DOS database.

It is one of the foundational technologies of personal-computer business software.

#tags

#dBASE #DBF #xBase #WayneRatliff #VulcanDatabase #AshtonTate #dBASEII #dBASEIII #dBASEIV #dBASE2019 #FoxBASE #FoxPro #VisualFoxPro #Clipper #Harbour #xHarbour #DatabaseHistory #DatabaseTechnology #DBMS #LegacyDatabase #LegacySoftware #DOS #CPM #PCSoftwareHistory #DesktopDatabase #DatabaseProgramming #DBFFile #DBFFormat #DatabaseMigration #FoxProMigration #dBASEMigration #SQLMigration #DatabaseModernization #BTree #DatabaseIndexing #DatabaseDevelopment #RAD #LowCode #NoCode #ODBC #ADO #Borland #BorlandDatabaseEngine #GIS #Shapefile #ESRI #DataManagement #SoftwareHistory #ProgrammingHistory #KnowledgeBase