When restoring from a backup, I’m curious how many of you expect to change the name of the database en route.
ie back up is of DB1
restore, into a new db to be named DByyyymmdd eg to compare files between two different dates.
I tried this today (RM8 Win10 under parallels) and although I was given the name dialog box to input a new name, I then received an error message that the database already existed - which the one the back up was of, was, albeit a later version of it, but the name I’d supplied to be restored into was definitely not in existence.
So I thought I’d try the tech support link - and that hung trying to reach v2.zopim.com. Admittedly that was from within Windows under Parallels trying to open Bing - which is available in the VM.
The tech support link from the home screen does work fine direct from the Mac side.
A different attempt (RM8 Mac Catalina) on the same machine) told me I couldn’t restore as the file was open, but the name I input again, definitely did not exist.
Just a curiousiity, as there are ways around this, albeit rather more convoluted and error prone if you get distracted en route of renaming and restoring 
There are workarounds, but they are all awkward. The cause of this behavior is that an RM backup file is a ZIP file in disguise, and the name of the backed up file is therefore embedded in the ZIP file in disguise. So the restore always restores the name of the database that is embedded the ZIP file which always the original name of the database. This behavior is not new in RM8 and has been around at least since RM4. I can’t remember about RM1, RM2, and RM3.
The simplest workaround is to restore to a different folder.
Another workaround which I find a little nerve racking is to rename my existing RM database and then to the restore in the same folder. I find it nerve racking because I now have to remember that my “real” database has the “wrong” name and my restored copy now has the “right” name, which is backwards of what I really want.
Another workaround which is more complicated is to rename your back file as a ZIP file, use a ZIP utility to rename the RM database that is embedded in the ZIP file, rename the ZIP file back to an RM backup file, and do the restore. The backup will then be restored to the name you chose when you did the rename inside the zip file. Not all ZIP utilities support such a rename, but some of them do.
I have long felt that RM should support restoring to a different filename. It seems to me that it should be able to do so by renaming the RM database that’s embedded in the ZIP file for you, silently and behind the scenes. Of course, it would have to remember to restore the rename inside the ZIP file after it was done with the restore.
There may be other workarounds, but those are the ones I can think of. The idea of comparing a backup file to a current file is such a common task that I do wish that RM would make it easier and more obvious as to how to do it.
1 Like
First things first. A backup file contains a named database (within an archive container). Restore always maintains the original name of that database. The name of the backup file itself can be changed, but not the name of the database. Restore always overwrites any existing database file of the same name as the original backed-up one… in whichever file location You choose during the dialogs. If that happens to be the one currently opened by You, it will warn You that it is about to overwrite it, unless You choose an alternate file location. The only way to change the name of a database is within RootsMagic itself using the Move/Rename under Tools>File Tools. *EDIT: Late reply without checking to see Jerry’s (phone interruption, sorry).
Ta all.
Yes, I’d not checked RM7 or earlier behaviour but I do dislike misleading input screens (the apparent option to rename).
Isn’t it great how RM8 makes us look more carefully at what we can/cannot already do 
When I am usually doing this sort of checking (old vs new databases compare ) I make sure I’m on a completely different machine as I KNOW that if use the different directory workaround on my production machine I’ll make the mistake of starting to edit in the wrong database particularly if relying on the list of recent databases used.
I wouldn’t dream of renaming my current production one, get way too many interruptions and would forget what I’d done and which one was which and where I was up too.
It happens
What I’d like to see happen here is for
EITHER
to miraculously rename the database as requested behind the scenes without overwriting the existing
which would (I presume) need the process to use some temp directory somewhere to unzip it into first then copy with new name into the requested directory, deleting the temp.
OR
the ability to apparently select a different name be removed entirely as it is misleading