Use a shared persistent table across client sessions ​

Two terminals can observe the same persistent table when they connect to the same Coordinator DB server and select the same managed database. A temporary table belongs to its connection and is not a way to share data between independent clients.

Check the session context ​

Start each client with an explicit database:

./coordinator client --database data

Create a normal table in one connection and commit its changes before expecting another connection to read them. Inspect system.tables with database and namespace fields if an object appears missing. An identically named temporary table can also make the observing session confusing.

Avoid repeating creation blindly ​

An “already exists” error may mean the desired persistent object is already present. Read its definition before dropping or recreating it. CREATE TABLE IF NOT EXISTS avoids a duplicate creation error but does not verify that the existing schema matches the application's expectation.

HTTP requests have independent sessions, so temporary objects created in one request do not survive into the next. Put related temporary-table work in one request or use a deliberate persistent staging table.

Do not start separate server processes against one shared database file to connect more terminals; multiple clients should use the same server.

See temporary tables, native session state and system.tables.