I upgraded to RM9 this morning and installed it in a new folder (and kept my RM8 installation in the old folder). I went to open a particular dataset for a current client project and it said it needed to convert the old RM8 database. Okay, no surprise, so I let it do that. But the new converted version – even though it’s considerably larger in Kb than the old version – is missing large amounts of info from the old version. Some of the persons I clicked on had no children attached – and when I went looking for them as individuals, they weren’t in the dataset at all. Also, I have a number of groups going for each dataset, one for each of the several subgroups of people, and many of those are ALSO missing from the list.
So I decided to put the whole thing aside for later and went to reopen the old version of that same dataset in RM8 – but when I clicked on the old RM8 .exe file, and then clicked on the old RM8 version of the dataset, the old program insisted it had to convert the dataset to the RM9 version. What the hell? The short of it is, I appear to have NO ACCESS to my RM8 dataset! There’s six months of work in that dataset and I’m going to be EXTREMELY displeased if I can no longer access it!
I know it’s brand new, but does anyone have any ideas about this? Would it even be possible to reinstall RM8 at this point?
UPDATE: I uninstalled RM9, ran CCleaner and tidied everything up, rebooted the system, then re-installed RM9. It still isn’t converting the datasets properly – large chunks of data missing, likewise, numerous groups – but at least now when I close RM9 and start up RM8, I can access my old RM8 datasets.
I think something was “dragging” across from the first RM9 installation and interfering with RM8, but that seems to be healed now. Incidentally, even though I had uninstalled the first installation of RM9, the registration key must be in a different file that lingered elsewhere, because it didn’t ask me to enter the key when I reinstalled.
I created a new folder for 9 and copied all my 8 databases to it.
I did that, too. I never throw away or overwrite anything if it can possibly be avoided. (And if it can’t be avoided, that’s probably not software I want to use.)
Even if you make copies in a new folder before upgrading your data, the very first thing you should do the first time you start up RM9 is to change the folder settings to point to your new folder structure. Then select the database file to convert from the Found Files section of the Open a RootsMagic file list, not the Recent File section which will still point to the original RM8 location.
Remember that RM8 and RM9 import from RM7, leaving the old RM7 database intact. But RM9 converts the old RM8 database rather than importing it, leaving the old RM8 database now being the new RM9 database and no longer usable by RM8. Re-installing RM9 will not fix that. Deleting RM9 from your system will not fix that.
It seems to me that every user converting to RM9 should set up a new folder to contain RM9 databases. Then, they should copy the existing RM8 database to the new RM9 folder and consider that to be the new RM9 database. Doing it that way will leave the old database intact. But leaving the old database intact is no longer automatic as it was in going from RM7 to RM8.
Another thing I always do when going to new releases of RM is to include the version of RM in the database name, e.g., jerryrm6.rmgc, jerryrm7.rmgc, jerryrm8.rmtree, jerryrm9.rmtree. Having the version as part of the database name is not a guarantee against shooting oneself in ones foot. But it can help.
That still leaves you with two issues. The first issue is getting back to your last good RM8 database. You will need to restore from your last good backup. The second issue is all the data loss you are seeing in going from RM8 to RM9. I think you will need to open a trouble ticket and submit your good RM8 database to the RM HelpDesk. Then they should be able to convert it to RM9 and see the data loss first hand.
I’m running both RM8 & RM9 separately in case of issues. I don’t know if it’s too late for you but what I did was to copy the whole RM8 folder and its contents to an external drive using OldRM 8 as a folder name to preserve the databases and .exe file. After installing RM9 and converting my databases I dragged OldRM 8 folder & contents to my hard drive and created a new desktop shortcut to it. It works fine but you have to browse for the original RM8 files as it tries to use the RM9 ones by default. I suspect that you will need to re-install RM8 in a different folder, run it and then, as Jerry suggests, install your latest backup that has media too. Good luck!
I’m already thinking about uninstalling both RM8 & RM9, so as to be able to do a clean re-install of RM8 using the older datebase format. Your suggestion of reinstalling RM8 on an external drive is a good one and I think I’m going to do that. I have a 4Tb drive that I use for incremental backups and there’s still lots of available space, so that’s not a problem. I need to have a properly working version of RM on my system until I’ve resolved the problems with RM9 because I have paying clients.
I’ve also followed Jerry’s suggestion of incorporating the version number into the actual dataset name, so they don’t get confused.
Even my suggestion is not perfect. If I were to open my jerryrm8.rmtree file in RM9 the name would not prevent it from being converted to RM9 format. It’s just that the rm8 in the name is a clue to me not to do that. So I copy jerryrm8.rmtree to a different folder (called rm9) and rename it to jerryrm9,rmtree. At this instant, jerryrm9.rmtree is still in RM8 format despite its name. But then I open it in RM9 and now jerryrm9.rmtree is in RM9 format as desired. In summary, you still have to be careful but changing the name to include the version makes it easier to be careful.
I’ve taken your advice and submitted a HELP request and attached backup (and therefore “clean”) copies of the problem dataset, and also of my other most heavily used dataset, because I’m curious to see if it has the same problems. If it doesn’t, that suggests the issue is with a particular dataset and not with the database-conversion system as a whole. (Because other folks don’t seem to be having this problem.)