[sciurius]

The SQLite database contains no global settings but it has all the metadata, collections setlists, songs, annotations and so on -- but everything is linked together, and eventually everything links to file paths. Backing it up without the files is rather pointless. You would have to restore it in a file tree that is identical to the one where the backup was made, or you'll get all files reported as "missing files".

[BRX]

OK, I thought that is a given.

If I want to make a backup of the database and settings only it is because my files are and stay in the same file paths. I keep the same file paths on different devices anyway (at least on my Android devices) not only because I'm expecting the sync feature. The backup would be (for me) for backing up and restoring the current system. Not necessarily on others or a new one.

[chrisss]

My plan is to provide a new option in the settings to "switch library", and this will be a list of databases the user has set up.
...
I'll be curious if this approach will satisfy the needs of those who have requested this type of feature in the past. ...

Yes, that is perfect for my own situation.
Can't wait.
And as always, thx for a great app + support.

[alanberris]

My plan is to provide a new option in the settings to "switch library", and this will be a list of databases the user has set up. On Android, I can support having those databases be in any folder the application has access to. For simplicity's sake, if "Expose Database" is disabled, I will only ask the user for a name for each library and each database file will be stored in the same directory in the internal application data directory. If expose database is enabled, then I'll let the user select the location for each database file, but I'll default to the storage location. Switching the active library will just update a preference file which the application will read at startup to figure out which database file to load. If you do something like perform a library backup, it will only back up the currently selected database. In fact, every action in the application will only act upon the currently active database. This will keep the feature and complexity from getting out of hand and it won't require huge design changes. Have multiple open databases at once is something I have no desire to support.

On Windows 10, I have to keep every database file in the application data directory next to mobilesheets.db - there is no flexibility in this as the SQLite library fails if the database files are not in that folder. So the user will be able to create multiple libraries and name them, but they will not have control over where the database files are stored.

I'll be curious if this approach will satisfy the needs of those who have requested this type of feature in the past. I'm open to feedback of course, but the one thing that I won't even try to support is using multiple database files at once.

Mike

Thanks Mike.
I play euphonium and now need to occasionally play baritone in the bands and want to use the appropriate library.  I set up individual libraries but hadn't realised about changing the name of the database. This will solve the problem of overwriting the files.