An index changes access order, not the physical DBF records
A DBF index stores keys derived from record values and references back to table records. It lets an application locate a customer number or display invoices by date without scanning and sorting the whole table every time. The physical DBF remains the source of field values.
This is why a general viewer can often open a DBF when its index is absent. The viewer reads physical record order. The original application may still fail or behave differently because it expects a particular tag, uniqueness rule, filter or collation.
Common companion formats
| Extension | Typical association | General characteristic |
|---|---|---|
| CDX | FoxPro and Visual FoxPro | A compound index can contain multiple named tags in one file. |
| IDX | dBASE/FoxPro ecosystems | Often a standalone index for one expression, though details vary by product. |
| NTX | Clipper applications | Commonly stores a single Clipper index order; driver and collation behavior matter. |
Other xBase drivers introduced additional formats. Equal extensions do not guarantee that every implementation uses identical headers, key encodings or collation rules.
What happens when an index is missing or stale
- The DBF may open, but records appear in physical rather than expected business order.
- Searches in the legacy application may slow down or report that an order is unavailable.
- A stale index can omit recent records or point to the wrong physical position after an unsafe file change.
- Rebuilding can fail when duplicate values violate an index expression intended to be unique.
- Different code pages or collation rules can change string key order.
Do not delete an index simply because it can be regenerated. The filenames, tag names and expressions are evidence about how the application organized its data.
Preserve index meaning during migration
- Archive every index file with the DBF and memo companions.
- Document index filenames, tag names, expressions, uniqueness and descending order when source tools can report them.
- Inspect the underlying DBF with DBF Viewer Pro and identify the actual columns used by the application.
- Translate lookup needs into primary keys, unique constraints and secondary indexes in the destination database.
- Test duplicate and null behavior before enforcing new constraints.
- Compare important legacy orders with equivalent SQL queries after import.
An index is not a substitute for documenting table relationships. Continue with the controlled migration plan, or use the Clipper guide when NTX files come from a DOS application.