Connection profiles

A connection profile is how TableCore remembers a server. It holds a name, a colour, a write-protection level and optional SSH tunnel settings — and, kept somewhere else entirely, the connection string.

#Create a profile

New connection in the explorer opens the dialog.

Test Connection opens a connection and reports what happened before you save anything. A profile that fails its test can still be saved — you may be adding it for a server that is not up yet — but you will know.

The connection string accepts what the MongoDB driver accepts, including replica set lists and mongodb+srv:// seed lists:

mongodb://localhost:27017
mongodb://reader@db.internal.example:27017/?authSource=admin
mongodb://a.example:27017,b.example:27017/?replicaSet=rs0
mongodb+srv://reader@cluster0.abcde.mongodb.net/?retryWrites=true

If you put the password in the MongoDB password field instead of the URI, TableCore strips it out of the URI and stores the two together anyway — the field exists so the password is not sitting in a text box you might screenshot or paste into a ticket. When you edit an existing profile, leaving the password field empty keeps the saved one.

#Edit, rename and delete

Right-click a connection in the explorer for Edit connection and Delete connection. Renaming is editing the name — there is no separate action, because the profile's identity is an id, not its name, so renaming never disturbs the workspace attached to it.

Deleting asks first, and removes the profile's secrets from the credential store along with it.

#What is in settings.json, and what is not

%LOCALAPPDATA%\TableCore\settings.json holds, per profile:

• the id, the display name and the colour tag,
• the write-protection level,
• the SSH tunnel's host, port, username, authentication method and private key path,
• the SSH host key fingerprints this profile has accepted, and whether it verifies them at all,
• when the profile was created and last used.

It does not hold the connection string, the MongoDB password, the SSH password or the private key passphrase. Those four are serialization-ignored on the model and go to the operating system credential store instead. This is not a setting you can turn off, and there is no plaintext fallback — Credentials and secrets is the whole story.

#Several profiles at once

Query tabs belong to the connection, not to a database or a collection. Switching database or collection in the explorer leaves your tabs alone; switching connection swaps the whole set. That is why the tab bar shows database.collection in the tooltip — two databases on one server can have collections with the same name, and the titles alone would not tell them apart.

Give environments different colour tags. The explorer row carries the colour, and it is the cheapest defence there is against running the right query on the wrong server.

#What comes back after a restart

TableCore restores the whole workspace, not just what you saved: every open tab with its text, its order, which one was active, and the connection, database and collection you had selected. The explorer tree reopens at the restored selection rather than collapsed.

What does not come back is the result of a query and any unsaved edits in the grid. A restored tab shows the query and runs it when you ask. Grid edits describe untouched rows by their position in a result that no longer exists, so restoring them would put your edit markers on somebody else's records — which is why closing a tab with pending grid edits still asks for confirmation.

#The connection state in the explorer

Each connection row says where it stands: not tested, connecting, connected or unavailable. A server that has gone away therefore looks different from one you have not opened yet, which matters when you have a dozen profiles and one of them is a VPN away.

#Upgrading from the older application

Profiles from the deprecated TableCore are picked up automatically. The migration reads both the roaming and the local application-data locations, merges entries without duplicating names, and leaves the old cache.json in place rather than deleting it. A corrupt cache.json cannot stop the application from starting.

Connection strings saved in the old format are not migrated. Re-enter them; there is deliberately no compatibility path that would read an old plaintext secret and carry it forward.

#Next

• Credentials and secrets — where your production credentials actually went.
• Read-only connections — and what the guard does not cover.