One page, the measurable facts. Figures are stated as of 2026-08-11 and carry their source; where a deeper reference page exists, this page gives the number and points rather than restating the mechanism. Nothing here is a roadmap item -- unbuilt things are marked chartered or absent, not implied.
Language, platform, license
| Item | Value |
|---|---|
| Implementation language | C++20 |
| Build systems | CMake presets; MSVC (Windows) and GCC/WSL (Linux) builds both exercised |
| Library structure | separate compiled libraries: xbase (tables/areas), xindex, memo, xexpr, dottalk_value, dottalk_tvui, under the dottalkpp host |
| Bundled carriers | SQLite (compiled in; 3.50.x observed at runtime), LMDB (index backend) |
| License | GPL-3.0-only, declared at the repository root |
| Optional bindings | pydottalk (pybind11) exposing a bounded native DbArea surface |
Table formats (three flavors, one engine)
| Item | Value |
|---|---|
| Classic x32 | version bytes 0x03 / 0x83 / 0xF5 (dBASE / Fox lineages). Support is scoped: tables, house memos, and house indexes -- see the scope note below |
| Visual FoxPro | version bytes 0x30 / 0x31 / 0x32, incl. autoincrement and varchar headers; VFP currency supported |
| x64 dialect | version byte 0x64; extended 64-bit header (xbase_64) |
| Record addressing | 64-bit (recno64 / recCount64 authoritative; 32-bit accessors return -1 above INT32_MAX rather than clamping) |
| Identity allocation | Runtime-proven. max(id)+1 taken under the writer's own lock -- bbs_store::next_id for SYSTHREAD / SYSPOST, and WORKSPACE NEW for WS_ID under a FLOCK. Ids are never reused, the scan counts deleted rows on purpose, and it self-heals after a hand-edited row |
| Header sequence slot | autoq_next (64-bit) is present in the x64 header and hydrated at open, and is reserved and deliberately unwired -- steward ruling R119, 2026-08-24. Not a pending lane: the question it would answer is already answered by the allocator above, and making the header authoritative as well would give one question two ladders. autoQNext64() has zero callers by design, and the ruling ships the three-part recipe for wiring it should that change |
No PACK on the workspace catalog | A consequence of the row above, stated where it is decided: max(WS_ID)+1 over a scan that counts deleted rows is the only thing preventing a reissued identity. Packing would renumber silently, so the verb does not exist |
| Long names | up to 256-byte table/field names in x64 metadata (ceiling raised from 128 in 2026-07; default 128), with classic 10-byte fallback descriptors -- two name planes, both real |
| Field types | classic types plus binary I/B/Y/T via a register-once codec registry; custom types register through the same path |
| Boundary proof | X64_METRICS regression exercises structure above the legacy 16-bit record/header geometry ceilings |
What classic x32 support means here, exactly
Classic 32-bit support is deliberately limited in scope, and the scope is worth stating precisely so nobody plans around a promise that was never made. What is supported is tables, memos, and indexes -- and specifically the house memos and house indexes we provide for v32:
| In scope for x32 | Detail |
|---|---|
| Tables | classic DBF table reading, writing, structure, cursor and record work |
| House memos | the memo carriers this project implements and maintains |
| House indexes | the INX and CNX containers this project implements and maintains, including realtime CNX order maintenance |
That is the whole claim. This project is not a Clipper, dBASE, or FoxPro compatibility platform, does not aim to reproduce a legacy application runtime, and does not chase every historical index or memo variant produced by three decades of vendors. The x32 lane exists because teaching a database engine honestly means showing the classic generation beside the new one -- not because this is a migration target.
If you need broader classic coverage, other platforms exist and are better suited. Harbour, xHarbour, Alaska Xbase++, XSharp, and the commercial dBASE/DBF tool families all carry far deeper legacy compatibility, and the ecosystem comparison names them with links. Choosing one of those over this project for legacy work is the correct decision, and saying so costs this project nothing.
Deeper: DBF_64 Specification · x64 Capacity Math · DBF Flavors and Index Defaults
Memo subsystem
| Item | Value |
|---|---|
| Store | DTX store, 64-bit object identifiers; canonical reference token is 16 hex characters |
| Semantics | append-new: an update returns a NEW token; erase and reopen supported |
| Payload policy | payload-agnostic -- the store never inspects contents; adversarially proven (seeded harness: 20,500 generations / 104,044 ops / embedded NUL and high bytes / 0 divergences across 4 seeds) |
| Demonstrated cargo | plain text through whole binary databases (a 94 KB container carrying 13 tables + 11 indexes, verified byte-for-byte as a unit) |
| Known boundary | the memo store performs its own file I/O and is not yet covered by the RAM virtual filesystem -- measured, recorded, and chartered as the prerequisite for true RAM-resident memos |
Deeper: FPT64 Memo Format
Index family
| Item | Value |
|---|---|
| Containers | INX and CNX (classic generation, RUN1: 4-byte record numbers, table-authoritative ordering); CDX (x64 generation, RUN8: 8-byte) |
| Engines | native maintenance and LMDB-backed keystore -- container format and maintenance engine are separate axes, chartered for full orthogonality |
| Capacity gate | CNX refuses tables whose record count exceeds what 32-bit record numbers can address, with a corrective message naming CDX |
| Realtime maintenance | CNX maintains order on REPLACE with no rebuild (proven); native CDX upsert/erase remain stubs on the RAM path -- reported as staleness, never silently |
| Cross-flavor policy | an explicit CNX attaches to an x64 table with an advisory (proven); the mirror direction is chartered |
| Transactional maintenance | SET INDEXTXN: buffered REPLACE/DELETE + COMMIT maintains the live index without rebuild (proven) |
Deeper: CDX / LMDB Indexing · Indexing Rules
Runtime model
| Item | Value |
|---|---|
| Work areas | 512 slots (a compatibility default with no architectural upper bound; per-slot cost measured at ~1.3 KB, allocated eagerly) |
| Relations | declared graph; traversal is refresh-driven; proven at 58 foreign-key relations over 43 open areas, walked by two independent consumers that agree by value |
| SELECT | SQLSEL: WHERE, ORDER BY, LIMIT, DISTINCT, COUNT(*); INNER / LEFT / RIGHT / FULL / CROSS join; aggregates with GROUP BY and HAVING; UNION / INTERSECT / EXCEPT; IN and EXISTS subqueries; expression projection; INSERT / UPDATE / DELETE with single-table transactions. Every result set verified against an in-process SQLite oracle over identical data in the same run. 13 specs are graded against that oracle: 6 in the default suite, 7 explicit-run. The bare SELECT alias ships behind SET MODE SQL (corrected 2026-09-09; this row called it absent). Still absent, stated plainly: cross-table atomic commit, stored NULL and memo-field DML, and subqueries over a joined outer scope |
| Transactions | WAL-backed COMMIT / ROLLBACK on buffered writes (proven at the record level) |
| Uniqueness | a uniqueness registry with declaration (SET UNIQUE), validation, and index-maintaining repair |
| RAM virtual disk | in-process, path-keyed byte files; hosts tables and native CDX; LMDB excluded by its own mmap contract; census-reporting; budget config with sizing recommendation and soft high-water |
| Locking | cross-process cooperative record/table locks, pid-stamped, with stale-owner recovery |
| Identity | member identities with roles/permissions; writes attributed to a real member |
Workspaces
| Item | Value |
|---|---|
| Snapshot formats | DTSHEMA 2 (the canonical schema -- portable, diffable, no absolute paths) and DTSHEMA 3 (the session -- measured flavor, own roots, cursor + selection state). Both are now spellable as V2 / V3; v2 remains the default. MINIDB 1 is the container -- posture plus table and index bytes -- and implies V3, so MINIDB V2 is refused rather than silently upgraded |
| Carriers | file or memo field -- one serializer, byte-identical text |
| Catalog | self-creating WORKSPACES table: unique id, name, measured dimensions, size, recursion-guard fields, supersede lineage, author, timestamps, roots |
| Verification | every memo save is read back through the token stored in the field and byte-compared |
| Hydration | disk-to-RAM or memo-to-RAM (zero disk reads), timed on every run; ~70-95 ms for a 13-table / 92 KB set |
| Simultaneity | several workspaces resident at once since 2026-08-26; OPEN and LOAD are both additive (R128, R130). Containment is declared, never inferred (R137): a workspace records its parent's durable id and its depth at birth. Open: cross-workspace name resolution, per-workspace RAM residency |
Deeper: Workspaces
Verification surface
| Item | Value |
|---|---|
| Curated regressions | 64 registered specs, 21 in the default suite (measured 2026-09-02); the registry stores each spec's doctrine, and the public list is generated from that same table. A spec joins the default suite on two green runs plus a measured coverage hole, not on judgement |
| Oracles in use | SQLite (row sets), shadow-model byte-compare (memo store), read-from-the-field byte-compare (workspace saves), census cross-check (RAM residency), derived-vs-declared reconciliation (governance) |
| Proof style | field-value markers in transcripts; a build stamp on every proof; corrections recorded in place rather than erased |
Deeper: Regression and Proof Testing · Proven Capabilities
Command and documentation surface
| Item | Value |
|---|---|
| Registered commands | 245 canonical runtime registrations measured by the normalization gate; 239 central-shell keys projected into the website catalog; 212 promoted to SYSCMD. Each count names a different authority boundary. |
| Functions | 75 implemented function specs and 75 SYSFUNC rows; the website catalog projects 73 core FunctionDoc rows plus 2 self-registering extension examples. |
| Self-documentation | HELP content, topics, and localization live in DBF tables the engine reads; manuals are generated from them; a cross-authority gate reconciles registry, catalog, help, and reflection on every gated commit |
| Localization | localized command surface proven for es/fr/de/it via the LANGUAGE regression |
Figures on this page that can drift (counts, ceilings, versions) are maintained against the same gates that measure them; if a number here disagrees with a gate transcript, the transcript wins and this page is the one that gets corrected.