# 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:

```sh
./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](https://coordinatordb.com/docs/reference/statements/create/table/temporary-table), [native session state](https://coordinatordb.com/docs/concepts/features/interfaces/client) and [system.tables](https://coordinatordb.com/docs/reference/system-tables/tables).