Troubleshooting

#Where the logs are

%LOCALAPPDATA%\TableCore\logs

or wherever TABLECORE_LOG_DIRECTORY points, if you set it.

Secrets are redacted before anything is written — passwords, cookies, private keys and connection strings — so a log file is safe to attach to a bug report. The same redaction runs on the technical detail shown in error dialogs, which you can copy out with the copy-details action.

#Where everything else is

%LOCALAPPDATA%\TableCore\
  settings.json      interface preferences and connection profile metadata
  workspace.json     open tabs and the selected connection, database, collection
  history.json       executed queries, 30 days
  queries.json       your saved query library
  entitlement.json   the signed entitlement document
  logs\
  backups\

None of these contain a connection string or a password. Those are in the operating system credential store — see Credentials and secrets.

#Resetting settings without losing your connections

Connection profiles live in settings.json alongside your preferences, so deleting that file removes both. To reset preferences and keep the connections, close TableCore and remove the individual settings keys, or:

1. Close TableCore.
2. Copy settings.json somewhere safe.
3. Delete settings.json and start TableCore, which recreates it with defaults.
4. Close it again and copy the Connections array from your saved copy back into the new file.

The credential store entries are keyed by the profile id, so as long as the ids come back with the profiles, the connection strings reattach themselves.

#Resetting the workspace

If a tab or a restored session is causing trouble, close TableCore and delete workspace.json. You lose your open tabs; nothing else.

#Common situations

#Reporting a bug

Use the support form in your account panel. It records bug reports, feedback and support requests.

Include:

• what you did, what happened, and what you expected — in that order,
• the version, from the account panel or the title bar,
• your MongoDB server version and deployment type — standalone, replica set, sharded cluster, or a hosted tier. A surprising number of behaviours differ between these,
• the exact error text, copied with the copy-details action rather than retyped or screenshotted,
• the query, if there is one. Redact the values, keep the shape — the shape is what matters,
• the relevant log file, if the problem is a crash or something that left no message on screen.

What not to include: a connection string, even one you think is redacted. If the problem is about a specific server, describe it rather than pasting it.

#Crash reporting

A crash is always written to your own computer, and never sent unless you say so. The file lands beside the logs, in a crashes directory under the application data directory, and the newest 20 are kept.

On the next start, TableCore shows you the report and asks. The dialog displays the whole payload, exactly as it would be sent — not a summary of it — so you can read it before deciding. You can add an e-mail address if you want an answer, and a sentence about what you were doing.

What a report contains: the application version and channel, the operating system, architecture and .NET version, the time, the exception with its stack and inner exceptions, the last 40 lines of the log, and whether an account was signed in — never which one. Connection strings, passwords, SSH credentials and anything in your credential store are stripped before the file is written, so there is no unredacted copy anywhere; file paths lose your account name too.

Settings → Privacy → Crash reports holds the standing answer: ask before sending (the default), send without asking, or never send. Never send still writes the local file — so you can read it, or attach it to a support request yourself.

#Getting the version

The account panel shows it, and so does the update dialog under Help → Check for updates.