Memo (M) fields in a DBF hold variable-length text or binary payloads. The DBF
record stores only a small reference; the payload lives outside the
fixed-length record. This page is a source-derived summary of the engine's memo
layer (include/memo/memo64.hpp and the memo backend).
Two memo backends
- x64 tables (
DBF_VERSION_64) usememo64— an LMDB-backed store. This is the current x64base memo format; it is not a classic.fptfile. - Legacy DBF/VFP tables use the classic FPT/DBT sidecar — fixed-size memo
blocks in a companion file, with a block pointer stored in the record. x64base
reads these for compatibility; new x64 tables use
memo64.
The memo reference (in the DBF record)
An M field in an x64 table stores a MemoRef64: an 8-byte unsigned
memo_id. A memo_id of 0 means an empty memo. The payload is fetched from the
memo64 store by that id.
The memo64 store (LMDB)
memo64 (version 1) keeps two named databases in an LMDB environment beside the
table:
- a values database keyed by
memo_id, holding a value header followed by the payload bytes; - a meta database holding control values such as
next_memo_id(the id allocator).
Each stored value begins with a 16-byte value header:
| Field | Width | Meaning |
|---|---|---|
| flags | 4 bytes | text / binary / compressed classification |
| reserved | 4 bytes | reserved for future use |
| length | 8 bytes | payload byte count |
Payload flags distinguish text, binary, and compressed memos, so the store can hold both character memos and arbitrary blobs.
Integrity
- A reference is valid when it is
0(empty) or resolves to a value in the store. - The value header's
lengthbounds the payload read. - Memo/reference integrity failures raise the canonical
fpt64facility error (e_fpt_block_invalid,fpt64/0x0001) — see Error Codes.
Practical tooling
- Use TupTalk to inspect record memo references.
- Use SmartList / export tooling for field-audit extracts.
- Use TableTalk when memo edits interact with buffered table state and
COMMIT.