You don't have the maintain the same path to the storage location when it comes to file paths in the database (those are relative to the storage location).
We did come to a resolution as far as the issue. BRX was creating a junction from their data disk to the LocalState directory - this didn't work on the desktop for some reason and created the problem with the database file. Without that junction, it worked fine.
I'm not sure I like the idea of encouraging most users to go digging into the LocalState directory and messing with the database file or letting them pick database files from other directories. This is something that my advanced users may deal with when using file synchronization software or other approaches to synchronizing multiple devices, but most users won't encounter anything like that. My solution to very large libraries is not to encourage users to find solutions outside the app - it's to improve the existing functionality so it works better for those large libraries. These improvements include things like allowing incremental library backups, and improvements to the library sync functionality (which only updates data that has changed so it's better than the library backup in that regard). Once I have time to focus on this more, I will of course be incorporating feedback from users on how to improve things, but those solutions need to make it difficult for users to make mistakes and mess up their libraries (I don't like dealing with angry users that make mistakes, as I've done in the past when I provided functionality to users that let them make bad decisions they didn't understand).
LocalState should only contain your song files, mobilesheets.db, database backups, configuration files (XML files), and some files generated by tools like Microsoft's AppCenter which is used for crash reporting.
Mike
We did come to a resolution as far as the issue. BRX was creating a junction from their data disk to the LocalState directory - this didn't work on the desktop for some reason and created the problem with the database file. Without that junction, it worked fine.
I'm not sure I like the idea of encouraging most users to go digging into the LocalState directory and messing with the database file or letting them pick database files from other directories. This is something that my advanced users may deal with when using file synchronization software or other approaches to synchronizing multiple devices, but most users won't encounter anything like that. My solution to very large libraries is not to encourage users to find solutions outside the app - it's to improve the existing functionality so it works better for those large libraries. These improvements include things like allowing incremental library backups, and improvements to the library sync functionality (which only updates data that has changed so it's better than the library backup in that regard). Once I have time to focus on this more, I will of course be incorporating feedback from users on how to improve things, but those solutions need to make it difficult for users to make mistakes and mess up their libraries (I don't like dealing with angry users that make mistakes, as I've done in the past when I provided functionality to users that let them make bad decisions they didn't understand).
LocalState should only contain your song files, mobilesheets.db, database backups, configuration files (XML files), and some files generated by tools like Microsoft's AppCenter which is used for crash reporting.
Mike