TableTalk

Table buffering, dirty/stale state, commit/rollback, and buffered table mutation workflows.

What it does

TableTalk names the table-buffering lane exposed through DotTalk++.

Its subject is buffered table state:

whether table buffering is ON or OFF
whether an area is clean or DIRTY
whether fields are fresh or STALE
which records have buffered changes
how COMMIT and ROLLBACK finish or discard pending edits
how mutators such as REPLACE and CALCWRITE interact with the buffer

Real local command surfaces include:

SET TABLE BUFFER ON
SET TABLE BUFFER OFF
SET TABLE BUFFER ON ALL
SET TABLE BUFFER OFF ALL
TABLE
TABLE BUFFER STATUS
TABLE BUFFER DUMP
COMMIT
ROLLBACK
REPLACE <field> WITH <value>
CALCWRITE <field> = <expr>

These workflows are about table-buffer state, not generic table browsing. Use SmartList, SmartBrowse, SimpleBrowse, and the browser pages for visible listing/browsing surfaces.

Diagram note: the current work-area/cursor-control diagram belongs with work areas and relation navigation, not TableTalk. TableTalk should get a dedicated buffer-state diagram only after the manual asset lane contains one that shows buffer=ON, DIRTY, STALE, COMMIT, and ROLLBACK honestly.

Runtime evidence should show output like buffer=ON, DIRTY, STALE [field], and buffered row counts before promoting a TableTalk claim.

See Current Project Truth and the canonical public repo deraldg/x64base.