<< Click to Display Table of Contents >> Navigation:  Tables > Data table formats > dBASE > dBASE table format

The dBASE / .dbf data table format

Each dBASE data table core file has the file extension .DBF - see also Associated table files.

Accessory files with various file extensions accompany each table file depending on data contents and table structure.
Please refer associated table files for various database formats.

A dBASE database consists of multiple files at least corresponding the number of tables in the database.
The database comprises the data files in the database directory folder.

Though having roots back to 1971 the modern dBASE .DBF format dates back to dBase III+ from Dec. 1985, but used in modern Windows environments the v. III+, IV and 5 format files accepts long file names and field names for vers. III+ to 5 with up to 10 all capitalized characters. The initial versions of dBASE for Windows and Visual dBASE were just version 5.0 and 5.5 of the dBASE application still limited to the dBASE table 5 and below.

With version 7 tables, as launched in 1997 with Visual dBASE 7, field names are allowed up to 31 characters and allows mixed case alphanumerics, spaces and underscores. However, with dBASE 7 any other non-alphanumeric characters are still disallowed and are converted into underscores on creation - probably the reason why dBASE 7 tables were never widely adopted and by other database import filters basically ignored.
This dBASE 7 table format is not supported by the Borland Database Desktop.

In BDE terminology dBASE level 3 means dBASE III+ synonymous with dBASE III Plus.
The version III file format (from 1984) differs from the level III+ format (from 1985) by not offering the Memo field, and version III tables are not compatible with later versions of the dBASE format.

See also SQL data type translation.

Old dBASE database terminology

In old dBASE and FoxPro terminology each table was called a "database".

Version specifics

Field types (table format versions)

*: In Borland Database Desktop the Numeric field type is referenced as "Number". Numeric is the proper native dBASE type name.
**: In the dBASE III+ table format the maximum allowed size for numeric fields is 19.
***: In Delphi the dBASE DateTime range is limited to dates from 0001-01-01. In the dBASE (dbase.com) documentation, the dBASE 7 DateTime field type is referenced as a TimeStamp field type.

dBASE and FoxPro tables stores up to 15-16 significant digits. Precise documentation about this is hard to find and may be due to the general problem (not just for dBASE/FoxPro) dealing with large decimal numbers via binary format.

Numeric entry

Due to the underlying text based storage of the traditional NUMERIC and FLOAT fields they have the capacity of storing any ASCII characters, only limited by the application interface in between.
Thus, if provided by the application, the dBASE numerics accept numeric entries as:

•plain integers or decimals, like 1234, -1234, 1234.567, etc.

•exponentials, like 1.23e25, 1.23E25, 1.23e-25, -1.23e+25, etc.

•hexadecimals, like 0x5F, etc.

all using the decimal character as needed and in this case using dot (.) as decimal separator as controlled by the system configuration.

This way the stored values in numeric fields of type NUMERIC and FLOAT may exceed the size limit of max. 20 positions by transforming the numbers into mantissa and exponentials all being kept within the size limit of the specific field.

dBASE/FoxPro numerics

Please see dBASE/FoxPro numerics.

Record deletions

As a common design for dBASE and FoxPro tables all versions, when deleting records they just applied a deletion marker and aren't actually removed from the table files until later packing the table.
Please see Table packing and security issues.

Record locks

dBASE tables support record locks, also on a shared local area network, as does the PdxEditor with dBASE files.

The _DBASELOCK field

Besides the basic record locking, specific info on date, time and who locked the record, is dependent on the optional specialized hidden character field "_DBASELOCK" (8 to 24 chrs) introduced with dBASE IV tables and onwards - characters 1-8 informing on change state, time and date, and the optional remaining 0 to 16 characters informing on the user having locked the record.
However, handling the "_DBASELOCK" field depends on specialized dBASE language commands (e.g. CONVERT, LKSYS()and CHANGE()) not handled by the BDE nor by the PdxEditor. Also, the _DBASELOCK field does not have any BDE Local SQL equivalent and cannot be queried nor modified by SQL.

Validity checks and Primary Keys (dBASE 7)

dBASE Tables version III+, IV and 5 did not possess the option of validity checks except via the database application.

Validity checks by the table system were introduced with dBASE 7 tables and differ from the Paradox design by being incorporated into the core .dbf table files.

Field validity checks offer checks for:

•fields where data is required

•min & max allowed value

•default value when adding records

PdxEditor respects the validity check settings of dBASE 7 tables, but cannot set or change these conditions except the Required attribute. However, querying the table and saving this to a new table will work just like mirroring the table freed from the check settings.

Also, Primary Keys (Primary Indexes) were introduced with dBASE 7 - however, do see the dBASE 7 Primary Key issues.

__________________________
PdxEditor Application Help, 18 May 2026; © 2010-2026 Niels Knabe