A DBF field type is more than a displayed value
Each DBF field descriptor supplies a name, a one-character type code and layout information. Traditional formats also allocate a fixed width inside every record. A value that looks numeric may deliberately be stored as character data because it is an identifier, while a modern Visual FoxPro numeric type may use a binary representation rather than printable digits.
Always inspect type, width, decimal count, nullability features and source dialect together. Guessing from the first ten values causes leading-zero loss, date errors and rounded financial data.
Common xBase field types
| Code | Meaning | Important behavior |
|---|---|---|
C | Character | Fixed-width bytes, normally padded; decoding depends on the source code page. |
N | Numeric | Often printable digits, sign and decimal point in a fixed-width field; blanks may represent no value. |
F | Float-like numeric | Meaning and storage conventions vary; do not assume IEEE binary merely from the label. |
D | Date | Commonly eight bytes in YYYYMMDD form; blanks and invalid legacy values require policy. |
L | Logical | May contain true, false, blank or unknown markers rather than a strict two-state Boolean. |
M | Memo | The record normally points to content in an FPT or DBT companion. |
Visual FoxPro adds types that need dialect-aware parsing
Visual FoxPro tables may contain binary integer, double, currency and DateTime values, plus Varchar, Varbinary, Blob or General fields depending on the table generation. Some tables support null flags stored outside the visible field values. A generic dBASE reader can therefore show nonsense even when the table is not corrupt.
- Integer: usually a signed binary value; endianness and exact layout must match the format.
- Currency: a scaled integer representation designed to retain fixed financial precision.
- DateTime: combines date and time components in a FoxPro-specific binary layout.
- General or Blob: may point into an FPT and can contain non-text payloads that should not be decoded as ordinary notes.
- Varchar/Varbinary: require awareness of actual length and null metadata rather than treating the full allocation as content.
Map business meaning before migration
Use DBF Viewer Pro to inspect the field list and representative records locally, then write a data dictionary. For each column record the DBF name, source type, width, decimal scale, encoding, blank/null behavior, proposed destination type and validation rule.
Character account numbers should normally remain text. Numeric money should map to an exact decimal type with sufficient precision. Blank dates should not silently become 1970-01-01. Unknown logical states may require a nullable Boolean or explicit status code.
Test the mapping against edge cases and reconcile totals after import. The SQLite/MySQL migration plan describes the staging and validation process, while the encoding guide covers character fields.