Tables

Create and manage tables in your schema. Columns support the usual SQL Server types, nullability, defaults, identity, unique, and primary keys. System tables (the platform’s own infrastructure tables) are protected — they can’t be altered or dropped, are excluded from the Data Engine’s default publication, and are hidden behind the “Show System Tables” toggle. The same protection covers the transient ingest scratch tables (_ingest_…, _verify_…, _baseline_…, _blkeys_… plus a GUID) that a sync or verify stages and drops again: they never appear as user tables, can’t be altered or dropped by hand, and any left behind by a hard kill are swept automatically.

Computed columns: a table can have computed columns (e.g. an id computed from business keys to make rows URL-addressable). Computed columns are read-only — never include them in API write bodies.

The Tables list shows a Features column with chips for what’s enabled per table: CP (Concurrency Protection), Audit (Audit Stamping), Events (Event Capture), Log (Change Logging), CT (SQL Server Change Tracking), RLS (Row-Level Security).

Avoid reserved T-SQL words in column names. A column named LineNo fails to create, because LINENO is a reserved SQL Server keyword — as are Key, Order, User, Percent, Public and others. Rename it (LineNumber, SeqNo): identifiers are quoted where possible, but reserved words still bite in generated SQL, ingest type-inference, and Data API OData filters.

Applying schema changes to the Data API. Creating, altering, or dropping tables, views, and stored procedures no longer triggers an automatic DAB regenerate — each success message says so. The change is saved to your schema immediately, but reaches the Data API only when you click Regenerate / Restart DAB. This lets you batch several schema edits into a single restart, which is the intended workflow.

A new table is not on the Data API yet. Creating it gives you the database object only. Add it under Settings → Data Engine (DAB) → Global Scope (or set_entity_exposure --expose true from the CLI/MCP) and then Regenerate / Restart DAB — until both are done, the Data API and the MCP data-plane tools (read_records, create_record, execute_entity, …) report EntityNotFound for it. Raw SQL (SQL Editor, query) sees it immediately; it doesn’t go through DAB.

“In the scope” is not the same as “being served”. The scope is your saved intent; the Data API keeps serving the configuration its running engine started with until a Restart / Regenerate succeeds. So an entity can sit in the Global Scope and still answer EntityNotFound — briefly between saving and restarting, and for longer if a restart failed (the previous engine keeps serving, so nothing goes dark, but the new entity isn’t live). From the CLI/MCP, list_exposed_entities marks each entity served: true/false and reports the version actually serving plus a warning naming anything that differs — check that before hunting for a bug elsewhere.

Dropping a table or view also clears its exposure. A scope entry whose object no longer exists can never be served, so drop_table / drop_view remove it from the scope for you (recorded in the audit log) and ask you to Regenerate. If you drop an object with raw SQL instead, the scope entry stays behind; the next Regenerate skips it and names it so you can un-expose it.