RM 11.0.4 for Windows (32 bit) - Windows 10 Professional 64 bit
The title says it all. If you have user defined source templates and if you use GEDCOM or drag and drop to copy people between existing RM databases, any user defined source templates used by sources that are used by those people will become duplicated. There is not a Merge Source Templates function in RM that can be used to cleanup the duplicate source templates.
The problem of duplicate user defined source templates and the need for a Merge Source Templates has been known for a very long time. For example, consider Merging Source Templates and Source Templates – Merge Duplicates However, I seem to have found a new way to shoot myself in the foot because of this problem.
I would emphasize that this problem doesn’t exist if you are using RM’s free form source template or if you are using RM’s built-in source templates. It only exists if you are using custom source templates. But even if you copy a built-in source template and tweak it a bit rather than defining a new source template from scratch, that still counts as a custom source template that has this issue.
The new way I found to shoot myself in the foot is that I deleted a person from my RM database and immediately changed my mind and wanted the person back. Deleting the person was intentional and not an accident. But I still wanted to undo the action. My RM session had been going on for a couple of hours and I didn’t want to restore from my most recent backup and lose all the work I had done during the two hour session. So conceptually what I did was to restore my most recent backup to a different folder and then to drag and drop that one person from there back to my production database. It was a perfect solution except for those duplicate source templates that were created.
What I really did was that I nearly always have a test database that is a recent copy of my production database. So I did my drag and drop from my most recent test database to avoid the problems associated with having to restore to a different folder. I think the trick of restoring to a different folder is dangerous because of how easy it would be to do it wrong and to overwrite your production database. There really needs to be a way to restore to a different file name in the same folder.
Because of this recent experience, I’m thinking about making a “Monday database” every Monday morning that would be a copy of my production database at that moment. Unlike any test databases I have, I would never update or play with my Monday database. I would simply replace it every Monday with a new copy. And it would be an *.rmtree file rather an *.rmbackup file so that it would be available immediately for this kind of short term data recovery via drag and drop. Except for this problem of the duplicate custom source templates. ![]()
I fixed my duplicate source templates using SQLite. But using SQLite to do updates is very fraught and is not recommended or supported by RM. So RM really needs a tool to merge duplicate source templates. Preventing them in the first place would be even better.
