[madoues]

Hi, 
I would like to make a major import to Mobile Sheets. In this case , I want to keep this import separate from my regular database. I know  Mobilesheets should take care of this no problem, but I do not want to take any chances whatsoever, backups or not. Right now the "Let Mobilesheets manage my files" option is unchecked.

So what are my options? 
1- Backup my database, erase everything and start a new database.

2- Would it be possible to just rename the database file and the db_journal file? One would expect in this case that MS would just re-create a new blank database file under the name "mobilesheets.db".
If this works, seems to me it would be quicker.

3- The ideal in this case would be of having the option of opening a second database file in MS. Correct me if I am wrong, but I don't think this is possible currently in MS. Has someone already asked for a feature such as this? Or am I the only one who thinks this would be desirable?

Dan

[BRX]

It has been asked a few times.

AFAIK you can simply rename in Android version. If it works for W10 iis for Mike to say.

[Zubersoft]

Yes, you can just rename the database file (if you enabled Settings->Storage->Expose Database). Make sure MobileSheetsPro is fullly closed before you do this. MobileSheetsPro will just create a new database file the next time you load it.

Yes, others have asked for the ability to have multiple databases/libraries. It's on my list of things to add when time allows, but I have some other higher priority things that need to be worked first.

Mike

[chrisss]

Could you possibly explain more fully / clearly how I could use and load 2 or more dbases, using this approach of renaming the dbase file?

Could I keep the dbases in 2 separate folders, each with their own mobilesheets.db file in that folder (exposed, as above), then change the storage location to 'the other' file folder, and restart mobilesheets?

thanks,
Chris

[BRX]

Even easier just duplicate the database dir, name it files1 or something and rename it back to files if you want tto use it's database (of course after renaming the current to files2 or something).

[chrisss]

Even easier just duplicate the database dir, name it files1 or something and rename it back to files if you want to use it's database (of course after renaming the current to files2 or something).

Thanks for coming back on it - I can make that work.

I can't help wondering if there is a way to 'insert' a startup page, in which the user can select a different directory path of the database to open, and if that might be relatively straightforward to code.  May need a switch in settings for user to activate it - off by default to not confuse people.  Or maybe store the X most recent locations selected.

All that aside, thx again.

[Zubersoft]

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

[sciurius]

As one of the persons who bugged you a long time for this feature: Yes, this is precisely what I would like to be able to. My primary goal is to keep sets of song projects separated. Really separated, including eliminating the chance to clobber a song in a project that is (accidentally) shared with another.

I'm looking forward it...

[sciurius]

Also, it would make troubleshooting a easier, since I would be able to reproduce a problem with a dedicated (small) database and send you the database dump so you have everything (data and settings) that matters.

[BRX]

Same here. Less of my memory problems. Quicker loading times and so on.

Inevitably there will be requests for transfer between databases which will involve more than just renaming the files and reloading.

But this might be possible with exporting and reimporting msf files?

(I also still like to have to make a backup file of the database and all settings *without* the files for the sheets. This would be also helpful for multiple database which all access the same files directory).

[Zubersoft]

Transfers between databases will be tricky. If the whole idea is the keep the libraries and databases separate, I'm not sure what the best way is to handle this. Exporting/importing msf files certainly will work for songs and setlists.

I've tried to avoid providing settings that allows users to potentially shoot themselves in the foot (because believe me, some most certainly will). When I used to allow song files to be excluded from backups, I would get lots of emails from users restoring backups without song files in them and having to explain that they didn't back up their whole library. I did not particularly enjoy those conversations, especially when those users didn't have copies of any of the files that were missing. Having said that, we may be approaching a point at which I want to provide different settings for basic users vs advanced users. Perhaps if I just add a toggle for this in the settings, basic users will be protected from changing potentially dangerous setting, but advanced users can take advantage of features I normally wouldn't want users messing with.

Mike

[sciurius]

I think being able to transfer using msf files is fine. If I want to physically share songs between databases I can import them from the same disk files while managing the files myself (yes, caveat emptor).

As for the settings-only database: it is good to be rather safe than sorry. With separate databases, it will be possible to create a single-song database to show and exchange a particular MSPro problem.

Copying settings from one database to another may be something to consider. However, to protect the innocent and unknowing user this would require a new backup type, one that doesn't clear the existing library upon restore.

[BRX]

I understand the caution, too. But the appeal of a backup without the files (sheets and audio) is that it is quick, doesn't need much space and also therefore is valuable all the more for separate databases. 
I have my sheets and audio dir mirrored on different devices and in the cloud. Also I backup and mirror my database manually (and have high hopes for the sync feature). So you see, why backing up the database with settings but without files is appealing.

A toggle, or settings for the advanced users (maybe even with double warnings "Are you sure... database won't include the files" etc.) would be terrific.

I think transferring between databases with msf files or reimporting is sufficient, too.

[sciurius]

For the sake of clarity: an MSPro library consists of (global) settings, an SQLite database with song data and song settings, and song (and sound) files. "Backup without the files" is a misleading term, since it would contain only the global settings. Therefore I would prefer to call it a "settings backup".

It is not the "Are you sure... database won't include the files" question... It is the restore that will (currently) delete the existing library and upon completion will yield a completely empty library. So in the case of restoring a settings backup, MSPro should not touch the SQLite database and existing files.

[BRX]

Well, I disagree.

I'd like to have a backup also of the SQLite database (assuming there is all the metadata, collections setlists, annotations and so on in it) with the settings and to be able to restore it without backing up or restoring the sheet and audio files. Yes, I can copy the database and restore it manually. But why wouldn't I want to restore an old backup and overwrite the current database or have to be warned about? 

That is the purpose of a backup, isn't it? Or am I misunderstanding something fundamental here?

If you meant, there should be a settings only backup which doesn't touch the database in a restore, I agree that this would be convenient, too.