Once remote database is not accessible you can no longer use its connections. We should have a local copy of all remote databases. Connection availability doesn't necessarily have anything to do with database availability - for example, database may be down for administrative reasons, and people could still work with the last cached copy.

Detailed specification

Multiple databases

Create new local database for each remote database. This could be done in current local sqlite (1Remote.db) or in separated files (<Database>.db from Database settings. Separated sqlite make more sense since then your team member can send others his own local cache and connections will just work. This can happen if, for example, remote database is currently not available and you never connected to it before. With single sqlite database, he can't do that without sending others his private connection data too.

Having multiple databases provides more options even in no remote database scenario - you can for example separate connections in multiple local databases for whatever reason - keeping them grouped per project, customer (if you are consultant) etc. Implementing multiple databases for remote database will automatically enable this option too, with minimal additional development.

With multiple local databases, 1RM should keep metadata about last successful connection in its own database. Since all databases are cached in memory too, we now have potentially 3 places where database is: memory, local file system, remote. Only memory is always accessible since even local database can get locked by external process.

Local FS and remote can be marked as authority (memory can never be authority) which determines how 1RM deals with disconnection. So original 1Remote.db is authority and MySql remote db is authority but not is local copy. 1RM keeps in memory metadata about last successful connection and next connection-retry time to authority (for both local or remote databases). When it succeeds, it should also store that in the local FS database (be it authority or not) and disable connection-retry timer.

Once authority is not available, editing connections coming from it should be disabled (they become read-only, for example by disabling Save button in connection editor.

Localized data for remote connection

Based on discussion #392 there should be need for local alternation of remote connections. Original idea was for allowing custom username - team members will either have their own domain names or local OS names. Others mentioned that other connection attributes could be localized too, such as Script before connect which is a good point.

Given that one may create a local copy of remote connection, I think this should be optimized for the main use case - custom credentials. Default credential is IMO not flexible enough in most scenarios particularly in common case where team members get personalized credentials to remote resource. This means that we should probably allow for both - Create default credential in 1RM configuration (e.g. domain username) and allow associating remote connection with local credential. This could be done on first run when specifying empty username on remote connection. 1RM could for example add another connection field in the local cache.

Technical

Multiple databases

1. Add new option in global configuration Databases - SQLite
   1. By default system comes with one default SQLite named 1Remote but user can add another one
2. For each remote database create local database
   1. Just as with local, allow path to be specified for local cache, by default it should use local directory and and have the same name as Database
3. By default, keep databases in db directory in order not to pollute root file system (no matter is it portable or roaming) and since we can have many databases now. This is the most natural place for it others will rarely touch.
   1. Add additional sugary option Open database directory.
4. When connecting to remote database, add new local copy using SQLite.
5. On the startup iterate all available local databases (be it authority or not) and add them to the connection list using groups
6. Add UX options:
   1. Collapse/uncollapse all
   2. Number of connections next to the database name in the list (e.g. 1Remote [35, 3 selected])

Forks

1. Add Local Json in Servers table in local copy of remote database
2. Provide Save Local button apart from Save, and keep any edited differences there (1RM already has connection diff due to the bulk edit attribute comparison)
3. Local configuration is always used over remote one, if it is defined
4. Add an option option Clear Local that empties entire Local Json
   1. It would be good (but not mandatory) for one to have point of view UX - remote vs remote with local for any attribute that has local override so he can switch to see a difference. This feature could have localized reset (clear only that attribute from the Local Json, not everything).

This is basically a fork, and the main benefit is that connection attributes that are not locally touched can still be synced from remote and affect local database.

Domain credential

Regarding credentials, there is also a merit for connection maintainer to specify AD/LDAP option remotely as this is widely used - I would do that for number of my servers, specify that connection uses teams domain name. If we have such an option ( e.g. Use local domain credentials) one would still need to provide in 1RM configuration his local domain credentials as I think there is no way to find out his password other then mimikatz.

1. Add in configuration editor a new option Use local domain credentials
2. Provide new global configuration a new section Global credentials
   1. Make one predefined value Local domain credentials that user should setup
3. If remote connection has option in 1. checked, use option in 2.1 if set, otherwise, ask for credentials on first connection
   1. User can choose any credential from global store or input a new one
   2. Remember credentials in Local Json if they are input by the user
      1. If global store credential is used, remember it by Name but not copy username/password in order for that user to be able to change them globally afterwards