Getting Started: FAQ

This FAQ is organized by how the project is actually described on the site: products, tools, lanes, formats, and proof status.

FAQ reviewed 2026-09-14. Each full-stack documentation reconciliation must check this page against changed product, command, interface, workspace, and contributor-operation claims. The matrix records UPDATED or NO_CHANGE, and the site freshness gate binds this review date to the documentation-progress authority.

Disposition: UPDATED. Unlike the 2026-09-02 review, engine source changed materially in this window, and one answer was not merely dated -- it was wrong. A shipped capability was described as absent: cross-table atomic commit landed 2026-09-11, and a sweep the following day corrected six statements across three SQLsel pages. This answer was a seventh and was missed, so the FAQ went on denying a capability the engine had, while the command catalog on this same site published GROUPCOMMIT as supported -- two published pages contradicting a third. The same sentence also called transactional DML single-table; it is not. The matching absence claim on DBMS and RDBMS was corrected in the same pass.

What else changed, and did not require an answer to move: the command catalog admitted GROUPCOMMIT and WORKDESK and rose 239 to 241; the HELP store shed a duplicated usage-contract family, taking line rows 29,700 to 18,566 without losing content; and the site moved from local candidate to published at release 145. The product, format, workspace, interface and contributor-operation answers were re-read against those and left standing. One gap is recorded rather than filled: no answer here describes where sys tables live or the path layout, because no page on this site does.

Products

Is this a clone of classic xBase?

No. x64base is a lineage evolution. It keeps the practical clarity of xBase tables, work areas, records, indexes, and command-driven workflows while modernizing the architecture around 64-bit formats, explicit specifications, object-oriented runtime services, documentation metadata, and cross-platform build lanes.

See: Engine Architecture, Ecosystem Feature Comparison

What is x64base?

x64base is the database/runtime side of the system. It handles DBF-family table work, work areas, cursor state, records, fields, memos, indexing, metadata, validation, and relation-aware runtime behavior exposed through DotTalk++.

It is best described today as active beta engine work, not a finished standalone commercial database product.

See: x64base Engine, Feature Crosswalk

What is DotTalk++?

DotTalk++ is the canonical command shell and runtime vocabulary for x64base. It exposes commands for opening tables, browsing records, moving cursors, loading workspaces, inspecting relations, mutating data, generating help, validating metadata, and running repeatable scripts.

DotTalk++ is active beta. Some command families are runtime-proven; others are canaries, integration surfaces, or planned lanes.

See: DotTalk++, DotTalk++ Language Guide

What is DotScript?

DotScript is the productized script form of the DotTalk++ command language. It is for repeatable command files, labs, validation runs, and automation.

Current documented syntax includes variables, comments, line continuation, IF / ELSE / ENDIF, LOOP / ENDLOOP, WHILE / ENDWHILE, UNTIL / ENDUNTIL, SCAN / ENDSCAN, one-level subscript nesting, and CSV/DBF import-export workflows.

See: DotScript, DotScript Language Guide

What is DotTalk++ Workbench?

DotTalk++ Workbench is the family name for GUI, TUI, CLI, browser, and preview surfaces over the same runtime concepts. The goal is parallel visibility: a table, workspace, relation, command, or proof should be inspectable from more than one surface without changing the underlying runtime truth.

See: Parallel GUI/TUI, Parallel GUI/TUI Docs

What is Arctic?

Arctic is the code name for the DotTalk++ Workbench TUI surface. It should not be used as the product family name. Use DotTalk++ Workbench for the family and Arctic TUI for the terminal interface lane.

See: Arctic TUI, Runtime Evidence Gallery

What is the Laboratory Campus?

The Laboratory Campus is the learning and collaboration layer for x64base and DotTalk++. LabTalk remains the project mark and legacy name, but public copy increasingly emphasizes the campus.

The campus is alpha: it mixes planning material, existing evidence, in-development labs, datasets, cases, GUI experiments, and proof-backed lessons.

See: Laboratory Campus, Laboratory Campus Overview

Tools And Commands

What are workspaces and areas?

Workspaces are wrappers over active database areas. An area is the runtime place where a table, cursor position, index order, relation state, memo behavior, metadata, and buffering state can be inspected and controlled.

This is why x64base is described as an object-oriented hybrid: classic xBase ideas remain visible, but the runtime organizes them through explicit service objects and work-area state.

See: Engine Architecture, Getting Started Overview

What is MINIDB -- is it only metadata about another database?

No. A MINIDB 1 memo container carries the database itself: workspace posture, table bytes, and native index bytes. The demonstrated development path can inspect that container and hydrate its members into the in-process RAM filesystem without using the original disk tables as its source.

That makes the workspace catalog a database of databases, not merely a catalog of database descriptions. The feature is Alpha development work, and a stored snapshot does not imply that every recursive or concurrent workspace operation is complete.

See: In-Memory Databases, Workspaces

Do MINIDBs have "minispaces," or can workspaces be nested?

"Minispaces" is a useful joke, not a product name. Workspaces can be nested: a workspace records its parent's durable id and its depth when it is created, cycles are refused, and DESTROY retires only an empty, childless workspace. Containers nest too -- a workspace holding a table whose memo field holds a container holding tables, opened and walked on 2026-08-21.

The lane is Alpha because the surface is still moving, not because the behaviour is unproven. Still open: cross-workspace name resolution, a per-workspace RAM subroot, and deeper container recursion, which is chartered and untried.

See: Workspaces, Current Work Lanes

What are TupTalk, TableTalk, and RelTalk?

• TupTalk names tuple-facing relation output: the row as a tuple, projected across related areas. Those projections read like joined records and are not join result sets -- they are correlated traversal from wherever the parent cursor is positioned, so moving the parent changes the output.
• TableTalk names table buffering, including dirty and stale table state.
• RelTalk names relation-facing workflows such as relation trees, descendant summaries, and relation-aware browse output -- and it is where declared joining lives: REL JOIN walks a parent and its children along edges you established with REL ADD, emitting one tuple per combination, which is a different output from the positioned projection above. SQL-syntax joining lives in SQLsel instead, declares nothing in advance, and reads no relation state at all -- two join surfaces answering two different questions.

These are lanes and product names around actual runtime concerns, not interchangeable labels.

See: TupTalk, TableTalk, RelTalk

Does DotTalk++ support SQL, and which command is the real one?

Yes, and the honest answer needs the distinction, because several commands carry SQL in the name and they are not the same thing.

SQLSEL and REL are where real query work happens. SQLHELP predates the workspace system and is kept as a reference surface, not as the query engine.

Maturity, stated plainly: this family is in progress. It runs and is actively developed, and that is not the same as a claim of completeness. The SELECT slice now carries the full join family, grouping and aggregates, set operations, subqueries and transactional DML -- each verified against an in-process SQLite oracle. The bare SELECT alias without the SQLSEL prefix ships behind the session switch SET MODE SQL -- corrected 2026-09-09, this answer called it absent. Cross-table atomic commit also ships, since 2026-09-11: a SQL transaction enlists every table it touches, each member prepares durably, and one group-log row decides all of them, so a multi-table commit reports 2 tables committed as ONE decision -- corrected 2026-09-14, this answer called it absent for three days after it shipped. Stored NULL in DML and subqueries over a joined outer scope remain absent. A command's page may also show a catalog status broader than its own contract claims (see below).

See: SQLsel, SQL conformance

What browsing and listing tools exist?

The site documents several table and browser surfaces, including SMARTLIST, SMARTBROWSE, SM, SMART, SIMPLEBROWSE, SB, BROWSE, BROWSER, BROWSETUI, ERSATZ, and RBROWSE.

SB is an alias for SMARTBROWSE. Browser names should be documented from command evidence, not inferred from labels.

See: Command Catalog, Runtime Evidence Gallery

What commands mutate data?

Data mutation needs special treatment because it changes records or buffered state. Important mutator families include REPLACE, CALC, CALCWRITE, and multi-record/multi-replace workflows such as MULTIREP.

Mutation behavior must be documented against buffering state: unbuffered writes, table-buffered writes, dirty rows, stale fields, validation failures, and commit/writeback boundaries are not the same thing.

See: DotTalk++ Data Mutators, SET Family

Does DotTalk++ support external tools?

Yes, some command families call external apps, shell behavior, images, web URLs, or helper tools. These commands should be documented with the same care as database commands because they cross a boundary outside the runtime.

See: Command Catalog, Coding Standards

Are there education commands?

Yes. The Laboratory Campus documentation tracks education-facing commands and lessons, including areas such as ASCII, SHELLO, RETRO, timed IDX labs, pre/post polling hooks, student code hooks, datasets, and proof transcripts.

See: Education Features, Laboratory Campus Examples

Lanes

What is a lane?

A lane is a named workstream with its own proof status. Examples include engine work, DotTalk++ commands, DotScript, SelfDoc, manual generation, Laboratory Campus lessons, GUI/TUI surfaces, historical source preservation, and the proposed application UI DSL.

Lanes prevent the site from flattening active, planned, proven, and experimental work into one vague product claim.

See: Current Work Lanes, Website Documentation Matrix

What is the SelfDoc lane?

SelfDoc is the documentation and metadata lane that collects command help, source comments, contracts, metadata, proof reports, and manual-generation artifacts. It is part of the system architecture, not just a publishing chore.

The long-term goal is vertical content generation: a command or feature update should flow from source and HELP metadata through SelfDoc/MDO reports into manuals, diagrams, and website sections.

See: SelfDoc Feed Pipeline, SelfDoc Website Publication

What is the Master Documentation Organizer?

The Master Documentation Organizer is the organizing layer for generated and curated documentation. It is intended to help gather command contracts, metadata, help text, proof artifacts, diagrams, screenshots, and manuals into repeatable publication paths.

See: Important Documents, Website Documentation Matrix

What is the application UI DSL lane?

It is an Alpha implementation lane for user-defined menus, windows, dialogs, controls, and event handlers. A DBF/FPT design-table contract, importers, manifest/refusal checks, and early wxWidgets, Tk, HTML, and character-cell consumers exist in development.

The text-command layer is still planned. DotTalk++ does not yet provide a finished FoxPro-style CREATE WINDOW / DEFINE BUTTON language for custom applications, and the known target-specific proof limits remain visible.

Example direction:

CREATE MENU MainMenu
CREATE WINDOW CustomerWin
CREATE DIALOG EditCustomer
DEFINE BUTTON Save
ON CLICK DO save_customer

See: Application UI DSL Lane

What is the historical source lineage lane?

It preserves earlier xBase, XDLL, xBase2, original C-era DotTalk work, recovery folders, AI-assisted false starts, and modern DotTalk++ with checksums, labels, and feature tags.

This lane exists because the project history matters: the modern system is larger than the original code, but the original source provides important provenance.

See: Historical Source Lineage

Formats And Engine

What table formats are used?

The project works with DBF-family formats, including classic/MS-DOS DBF, VFP-style DBF, and x64 DBF_64 work. DBF_64 is the newer 64-bit table direction, not the only DBF flavor named on the site.

See: DBF Flavors and Index Defaults, DBF_64 Specification

What memo formats are used?

FPT64 is the documented 64-bit memo direction. The memo subsystem is also discussed as an object-oriented architecture with MemoRef, MemoManager, MemoObject, and MemoStore concepts.

See: FPT64 Memo Format, Engine Architecture

What indexing work exists?

The site documents INX, CNX, CDX, and LMDB-backed indexing work, including default and optional index choices by DBF flavor where known. Some indexing work is runtime-proven; some is active integration work.

See: Indexing Rules, CDX / LMDB Indexing

Does x64base support CSV import and export?

Yes, CSV import/export and DBF/CSV workflows are part of the documented command and DotScript surface. Those flows should be tied to command evidence and not described as a generic spreadsheet feature.

See: DotScript Language Guide, Command Catalog

Does x64base support DDL?

DDL is documented as a command family and should be tracked with command catalog evidence, data dictionary behavior, schema/proof artifacts, and any limits discovered by runtime tests.

See: Command Catalog, Feature Crosswalk

What about record locking, triggers, buffering, and cursor control?

These are commercial-database-style feature areas tracked in the engine and command documentation. The site should distinguish runtime-proven behavior from active or planned work.

Buffering is especially important: TableTalk tracks table-buffer state such as dirty rows, stale fields, validation failures, and writeback behavior.

See: Feature Crosswalk, DotTalk++ Data Mutators, SET Family

What about language, locale, currency, and international support?

The system tracks locale, language, settings, and field/data type work as part of the engine and SET-command family. International currency and locale behavior should be documented from actual command coverage, field-type behavior, and tests.

See: SET Family, Feature Crosswalk

Interfaces

What interfaces exist today?

The documented interface surfaces include:

• DotTalk++ CLI command shell.
• Arctic TUI code-name surface.
• DotTalk++ Workbench GUI and preview lanes.
• Python/Tk preview tools.
• Website documentation and product pages.

Each surface should point back to runtime evidence when possible.

See: Parallel GUI/TUI, Runtime Evidence Gallery

Can users build their own GUI screens in DotTalk++ today?

Not yet through a finished user-facing DotTalk++ language. The Alpha UIDEF lane can already describe an application in DBF/FPT design tables and feed early wxWidgets, Tk, HTML, and character-cell consumers. Existing Workbench surfaces can therefore exercise real implementation, but the proposed text verbs, cross-target parity, and remaining native proof are not complete.

See: Application UI DSL Lane

Is the website itself an x64base product?

Yes, conceptually. The website is part of the product system because it publishes x64base/DotTalk++ documentation, proof artifacts, diagrams, screenshots, generated content, and curated explanations.

Practically, the website is currently a separate static site project. The intended direction is to keep aligning it with the SelfDoc/MDO vertical feed so source truth, HELP, contracts, manuals, and website pages do not drift.

See: Website Documentation Matrix, SelfDoc Website Publication

Local Preview And Contributor Surfaces

What is the difference between ports 3000 and 3002 locally?

The website development server listens on port 3002. The local AI reports gateway listens on port 3000: it serves /AI/ and /AI/console, and proxies ordinary website routes to 3002. Use the normal start-ai.ps1 launcher so it verifies that the expected ports are free and checks gateway health instead of adopting or killing an unknown listener.

Search needs a production-built Pagefind index. Use the launcher's built mode when testing search; ordinary Next development mode is for live editing.

What is /lab, and is it published?

/lab is a local-only working surface for experiments, inventories, and review-needed material that should not yet become a public claim. Its index lists nested Lab pages such as /lab/experimental in local preview. The route is noindex, removed from publication output, and protected by a publication abort if it survives the strip step.

Do not link public documentation to a Lab page. Promote the underlying content into the appropriate public documentation lane first.

Why can /lab still show a route-parameter error after its source is fixed?

The Lab uses an optional catch-all route. Static export requires its parameter list to include both the empty root slug and every nested content slug. Changes to generateStaticParams() are startup-time route changes, so an already-running Next development server can keep the old list. Restart only the verified website server on port 3002; preserve the reports gateway on port 3000.

The proof is not merely that the build exits successfully. The export must contain both out/lab/index.html and the expected nested Lab pages, and the proxied /lab/ request must return the Lab index without a runtime error.

Status And Proof

What does runtime-proven mean?

Runtime-proven means the behavior has current evidence: source, command output, screenshots, transcripts, smoke tests, generated reports, or reviewed artifacts. It does not mean every edge case is complete.

See: Runtime Evidence Gallery, Feature Crosswalk

What does supported mean on a command reference page?

Narrower than it sounds, and this is worth knowing before you rely on it.

In the command catalog, supported means the command is registered and dispatchable -- it exists and it runs. It is not a maturity rating, and it does not promise the surface is complete or that it will not change.

A command's own @dottalk.usage contract in source carries a separate status: field, and the two can disagree. Measured 2026-09-02: of 109 commands that declare both, 33 publish supported while their contract says something narrower -- experimental, developer, stub, sample-extension, or in one case deprecated. Every disagreement runs the same direction, because nothing currently compares the two.

So: supported on a page answers "does this run", not "is this finished". Where a command's own page or contract says experimental or developer, take the narrower claim. The vocabulary is being split into separate axes (audience, completeness, lifecycle) so one word stops answering several questions at once.

What is active beta versus alpha?

x64base and DotTalk++ are active beta: real runtime behavior exists, but the project is still evolving.

The Laboratory Campus is alpha: it combines collaboration planning, teaching material, existing screenshots, datasets, cases, and in-development tools.

A lane stays labeled planned until it is implemented and proven. Where a lane has advanced, the label moves with it: the application UI DSL (UIDEF) is now an Alpha implementation lane rather than planned-only, while its text-command layer (CREATE WINDOW, DEFINE BUTTON) remains planned. Corrected 2026-09-02, when this answer still cited UIDEF as the example of a planned lane while the UIDEF answer above already called it Alpha -- two answers in one FAQ disagreeing.

See: Current Work Lanes, Laboratory Campus SDLC

Why so much emphasis on education?

Because database systems become understandable when learners can inspect the layers: file formats, fields, indexes, work areas, relations, buffers, commands, help text, diagrams, and proof artifacts.

The educational goal is not to simplify the system into slogans. It is to make the real machinery visible enough to learn, test, extend, and document.

See: Laboratory Campus Overview, Education Features

How should new features be documented?

New commands, functions, field types, or interface behavior should move through the same vertical path:

source / command -> usage contract -> HELP / metadata -> SelfDoc report
-> proof artifact -> manual section -> website section

That is the repeatable path the site is trying to expose.

See: Coding Standards, SelfDoc Feed Pipeline