UPDATE 2022-05-14: better than GEDCOM is to convert directly from RM8 to RM7 for which there are a couple of possibilities:
- RM8’s File > Export Data > DropBox creates a copy of the active .RMTREE file to a RM7 compatible .RMGC file intended for use with the RootsMagic Mobile app (now retired for Android). It is a complete conversion except, in my test, for Roles for shared events, which should be an easy fix for the developers. In my test, the RoleTable was empty which invalidates every shared event.
- Use one of my SQLite scripts that were developed subsequent to this original post:
Direct Import of RM8 database into RM7 – Part 1
Direct Import of RM8 database into RM7 – Part 2
Once the RM8 Export to DropBox is fixed, it would be operationally more attractive and is supported by RM Inc.
Issue
As of writing, still no Book Publisher feature in RM8 and along with other persistent issues, some users wish to return to the RM7.5 database from which they had ‘upgraded’. However, the only way back using the RM user interface is via #GEDCOM which, along with other attendant losses (see GEDCOM & DnD transfer losses) does not import #namedgroup and custom #reports. The original #RM7 database contains the custom reports and book specifications and possibly useful groups as they existed at the time of committing to the upgrade but importing into it results in an overload of duplicates, as described by PatrickR in his Apr 9 post to the RootsMagic User Community: Is there a way to copy custom reports to another database?
A solution
Years ago, I had an approach to creating a quasi-empty shell database file from a populated database that I thought might be adapted to this particular case: Depopulate but keep Customs, Places, Sources. Maybe a variant that depopulated but instead kept groups, custom reports, and book definitions could be used to import the GEDCOM from RM8 to good effect. I’m pleased to report that my experiment was successful, to the extent that GEDCOM transfer allows.
Procedure
- Review GEDCOM & DnD transfer losses and, in your RM8 database, ensure that your Fact Types are all set to export to GEDCOM. Run the RM8 database tools and Export the database having chosen to export everyone and everything.
- In RM7, make a copy or backup of the original database from which the RM8 ‘child’ was created. Run the RM7 database tools. Close the RM7 database file.
- Open the RM7 database file with your SQLite manager (one with a fake #RMNOCASE extension), load and execute this SQL file:
- Reopen the now-depopulated database file with RM7.
- Run the RM7 Database Tools.
- Import the GEDCOM file from RM8 choosing the option
Preserve record numbers - Done! Review what you’ve got. Note that the Media Gallery has to build thumbnails anew.
Possibilities
It should be possible to transfer data more completely by directly copying data from the RM8 database to the RM7.5 database via SQLite. However, because of changes in database structure, it’s not straightforward for several tables. Also, there may be serious incompatibility between the ConfigTable content of the two versions which may preclude the carryover of custom reports and other settings.
I may look at your procedure and take advantage of it. I’m still on RM7 for all the same reasons that some early RM8 adopters might wish to move back to RM7. But I would actually like to convert to RM8 and I would probably do so if only I could still move my data cleanly back to RM7 as needed.
I really wish there was a clean database copy way to get the data back and forth, for example such that RM7 could import from RM8 the same way that RM8 can import from RM7. There are some tricky things that would have to be handled. I think you would have to give up on getting Tasks in RM8 and ToDo Lists in RM7 back and forth, but most of the rest seems at least conceptually possible even though some of it is very tricky.
I’ve got a script that, so far, directly imports a RM8 database into a RM7 database
except for ConfigTable, TreeShare, FamilySearch, To-Do & Research items. The only obvious problem encountered so far is Find Everywhere crashing in Citations which I’ve now attributed to an unfound fault in the data of a particular RM8 database.
I’m a novice when it comes to SQLite but poking around my RM7 database it seems that Custom Reports are stored as Record Type 3 in the Config Table. Is it not possible to copy these records from one table where they exist to another where they don’t exist?
Also, the RM8 File>Export Data>Dropbox converts a RM8 database into a RM7 database for use by the mobile app. I tested this on an Android 8 installation and the database was read fine by the mobile app and the people I had added to RM8 were there as well as all their events and places.
Please correct me if I am seeing something incorrectly.
RE: RM8 File>Export Data>Dropbox converts a RM8 database into a RM7 database
Your success differs from what I observed some months ago. The RM Dropbox export failed in the RM7 desktop app because it was a subset of tables, including only those needed by the Mobile app. So I just now exported a RM8 file that originated in RM7 with custom reports and was pleasantly surprised that the database structure appears complete for RM7 desktop and its Custom Reports appear to have survived the round trip.
How transparent the export is remains to be assessed. I’m sure there will be some issues around the conversion of Folders and Tasks to Research Items and Research Logs as I found out in my attempt at a direct conversion. And there may be some issues with reports newly created in RM8 if it has a dual mode to handle legacy report settings from pre-RM8 and another mode for new reports with the RM8 report engine.
Thanks for your comments.
I forgot to add it was read correctly by RM7 and everything seemed OK.
RE: copying ConfigTable records for Custom Reports to another database
I’ve done that indirectly with versions earlier than RM8 (see https://sqlitetoolsforrootsmagic.com/depopulate-but-keep-customs-places-sources/) and it should work the same in RM8. I’ve yet to try between RM8 and RM7 and I’m wary that it may not work as I understand that the report engines are different. That does not necessarily mean that the metadata or settings data formats are different but they may well be and that could throw up issues with backward (or forward) compatibility. Let us know if you carry out such tests andwhat your results are like.