[BRX]

Hi Mike,

I have surprising difficulties to set up MSP on my new W10 desktop with my old database and the old files. 

I don't want to make a backup with files because my db and files are > 50 GB already (and if you remember that's the reason while I continue to ask for a backup
option without source files). I sync my files over different devices (always to the same path) so I don't need and want to use MSP's internal backup.

 Here's what I did (worked the last time when I set up MSP on my W10 Surface):

- installation and start of MSP
- choose another file directory in the settings for the source files (in this case e:\sync\noten)
- close MSP and move my source files into the new file dir
- copy my lates mobilesheets.db from my surface to the localstate directory

Am I missing something? Shouldn't my db be usable with the new MSP if the paths to the dir with the files are identical?
(And there isn't a "manage your own files equivalent" on Win10, right? At least I can't find it in the settings.)

If I open MSP again the background stays dark, tries to load the db and says something (translated) like "database couldn't load all automatic backups. You have to restore the library manually".

After that the background still stays dark and displays no data. A bit later it displays the introduction screen of MSP.

What am I missing?

[Zubersoft]

Everything you did is absolutely correct. If you completely closed MobileSheets, copied over the database file, then restarted the app and it gave you that error message, it means MobileSheets is unable to access the database file for some reason. This usually comes down to corruption of some kind. You can try copying the file again as perhaps something got messed up when the file was copied, or if there truly is corruption in the database, send it to mike@zubersoft.com, I'll try to repair the database using sqlite and I'll send it back to you. I can also use sqlite to run a "pragma integrity_check" on it to see if it detects any problems before doing anything else. If you are comfortably running sqlite, you can run that check on the file yourself as well. 

Mike

[BRX]

Mike, sadly my problem on my new desktop remains, even after updating to the newest version.

I've sent you an email with a link to my database. Maybe you can find something that explains why it can't be read from my new installation.

It's strange that this db works finds on my surface and when I copy it to my other W10 desktop pc.

[KHS]

Mike, sadly my problem on my new desktop remains, even after updating to the newest version.

I've sent you an email with a link to my database. Maybe you can find something that explains why it can't be read from my new installation.

It's strange that this db works finds on my surface and when I copy it to my other W10 desktop pc.

Did you guys ever solve this? I'm considering the same strategy with my setup (using W10 on 3 different machines, 2 desktops in 2 different locations for testing imports and one Surface Pro tablet for the final corrected and tested results).

I sure wish I didn't have to maintain exactly the same path to my MobileSheets Storage Location on the tablet as I use on the desktops, inasmuch as I have multiple drives and drive letters and file management on my desktops and only C: [so far] on the SurfacePro. I realize that's a separate issue from what you guys were trying to figure out.

It would sure be great if MSP could react to a "missing" or defective .mb file by prompting the user for a different .mb file in a different location to copy into LocalState. I agree with you that having to copy all the PDF contents for a backup of only what's specific to MSP is going to become undesirable as my library grows; it may lead users to backup less often. Obviously, the default option is useful to most users.

BTW, are you losing ANYTHING by only copying over the MobileSheets Storage Location folder and the .DB file? I see other stuff in LocalState that I don't understand (and don't want to).

Thanks. - Kevin

[Zubersoft]

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

[KHS]

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 are things 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

Is there any harm in the user putting useful stuff in his Storage Location? For example, when I want to check on what's in my Local State folder, I use a Windows shortcut to point to that deeply-nestled folder (sounds a bit like what your other user was doing). I'd like to keep that in my MSP Storage Location, but if having "foreign" objects there can cause screwups, I'll find somewhere else to put it for easy access. Thanks.

[Zubersoft]

It's perfectly fine to put whatever files you want in the storage location. MobileSheets won't know about them and it won't impact MobileSheets in any way.

Mike