[sciurius]

[This may also be of interest for people having very big (multi-gig) data sets]

I maintain several collections for different purposes. I have a collection for my pop-choir, one for the irish folkband, one for a vocal group, and so on.

Note that I use the word collection in the pure sense, not to indicate a MSPro collection (although currently I do use MSPro collections for my collections).

All these collections are very distinct and actually sometimes get in the way. When I'm playing with the band I do not need (or want) the other songs, etc.

I would like to request an enhancement that will make it possible to maintain distinct collections in distinct databases.

An added benefit is that it will no longer be necessary to make a backup of all the songs for all collections when I modify something for a single collection only, resulting in smaller and better to maintain backup sets.

[Snard]

That's a very nice idea. To go with it, it would be nice to have a way to launch MSPro with a particular database from its own desktop icon.

[gerryfitz]

That's a very nice idea. To go with it, it would be nice to have a way to launch MSPro with a particular database from its own desktop icon.

It would be nice to have this feature, but I seem to recollect it has been suggested before and there was some reason it couldn't be done.

[Zubersoft]

Would it be sufficient to provide an option to switch which database file is loaded, and allow a way to create a new database file?

[sciurius]

I think that would be sufficient for now. Maybe later some of the settings would need to be stored in the database instead of being global only.
Thanks for considering this!

[Harry_M]

I would like this feature, too!

[sciurius]

I would like to revive this feature request.

[sciurius]

I'll add a use case.

I have songs for several different projects (band, choir, etc.). The songs are distinct and I use collections to group them.
Within a collection, I need another level of grouping. There are songs ready for use, songs that need practice, songs that are under consideration, and so on. I currently use setlists for this, but this tend to get confusing with the 'real' setlists.
When working on a project, I want all project-related songs at hand and I'd prefer none of the other songs to show up. They just get in the way.
As far as I can see, this would best be realised with separate databases, one for each project. Within the project I can use collections for the song categories, and setlists for setlists.
If there's a good alternative I'd be interested to learn.

Separate databases would also be helpful in setting up small example sets for testing, without the risk of damaging real song collections.

[Zubersoft]

I agree that it would be a very useful feature. I used to have a database import/export feature in the original MobileSheets (that users constantly mistook for the library backup/restore functionality). This feature is going to look very similar, except that I have to decide if it makes more sense to ask the user to pick the various .db files to switch between, or if I manage it and just provide them a list of "libraries" they've created. If I do the latter, I would be responsible for managing the .db files in different storage directories. I imagine you would prefer the former.

Mike

[sciurius]

I think it is slightly more complicated.
An instance of MSPro consists of a collection of settings, a database, and a collection of songs. Basically, all that gets included when making a backup (.msb). The database and songs can already reside in a user-specified location.
Theoretically (and maybe also practically) I could make a .msb for each musical project and load the appropriate .msb when switching projects. For this to work reliably, MSPro should keep track whether there are data changes that have not been stored in a backup and issue a big warning if so. Better still, automatically save everything in a .msb if necessary and restore the new .msb.
Maybe in combination with a backup option to not include the songs unless MSPro is configures to manage them.
Just thinking aloud...

[Skip]

I think the most difficult hurdle will be identifying/separating each db in such a manner there is nothing the average, non tech user can screw up.

[jagny42]

Just thinking aloud:
With multiple databases this problem arises: If I make a change to a song or add an annotation or add, for instance, a genre to a song, if I have it in multiple databases how will all copies of that song's characteristics be updated in each database?
Perhaps an alternative solution would be to keep only ONE database but add metadata indicating which "Collection" or "Collections" you want this song to belong to and have the capability to ONLY LOAD those songs that you want to see in a particular session.
Like I said - just thinking aloud.

[sciurius]

If I make a change to a song or add an annotation or add, for instance, a genre to a song, if I have it in multiple databases how will all copies of that song's characteristics be updated in each database?

They will not, and that is exactly the purpose.
As I see it: When you update a song file on disk, and that song is external to MSPro (not managed) and also used in another databases, switching to that other database will pick up the changes. This is no different from otherwise changing an external song file.
However, adding annotations, notes, etc, to a song applies to the current database only. I may, and will, have different annotations for the same song, depending on whether it is used in (eg.) a choir or a cover group.

The semantics would be identical to making a backup set of DB1 and then restore the backup set (with total clean) of DB2. Anything not physically in the backup set is essentially shared, everything else is private to this database.

[sciurius]

Elaborating on this, some questions for Mike...
Given a configuration where song files are not managed by MSPro.
When I make a backup, all song files are included in the backup set (.msb file).
Upon restore, I assume that these included files will be ignored, since they are not managed by MSPro. In fact, they could reside in a location MSPro doesn't even have write access to.
This leads to two possible enhancements:
1. In the library backup dialog, add a checkbox to control whether these files are included in the backup set. Checked by default since that is the current situation. Unchecked means the filenames are stored (as part of the database) but the content is not.
2. Upon restore, add an option to a) attempt to restore non-managed files in the original location (wishful? dangerous?) or b) to restore non-managed files as managed files, or c) do not restore them, but check that the actual file is present, or d) ignore them.

[Skip]

I think this concept has entered the arena of the top 1%ers. If separate dbs are offered they probably need to stay as close as possible to the way the main db works as is feasible with few, if any, options. There are too many 'fiddlers' around thinking they understand options and they end up hosing their installation and losing data.
Maybe it would be better if a capability to import a database were included for those who have the expertise to use one, with no capability to manage/modify it beyond what's already available in MSP. Maybe that's what is being proposed for all I know. Or this whole capability could be developed as in-app purchase as it seems to be fraught with possibilities for the competent and danger for those with lessor abilities [95 % of us ].