Is there a way to copy custom reports to another database?

Because of the current inadequacies of RMG8’s reports, I copied the data back to RMG7; I have been using RMG8 since it was released and will continue to wait for improvements, but the various unresolved (unaddressed?) issues with reports is causing too many problems.

The only way to move from 8 to 7 is via GEDCOM. I cannot copy it back into the old database, as I end up with 10,000 duplicates. When I copy it into a new RMG7 database, I end up with all the records intact, but no custom groups or custom reports.

Is there a way to globally delete all persons from a database, leaving the groups and custom reports intact, and THEN import the GEDCOM?

Or, as the idea I was originally seeking, is there a way to copy the old Custom Reports and groups into a new database?

There might be a way but not within the RM user interface. And I’m doubtful that it would result in fully intact reports, especially as it has been complicated by the migration of the desired data to RM8 with changes to them therein which you want to bring to RM7 which has your groups and custom reports. The import of a RM GEDCOM gives the option to preserve record numbers and that is essential to the procedure, those record numbers are only for persons and, maybe, couples but not for sources and citations and that might have adverse consequences.

You would use SQLITE to clean out selected tables from a copy of your RM7 database and then import the GEDCOM with the preserve option. An old example of this from the RM4-5 era is at Depopulate but keep Customs, Places, Sources #database #places #placedetails #sourcetemplates #sources #facttypes #custom #media #roles – SQLite Tools for RootsMagic . The RM5 version probably needs updating for RM7 and this particular goal.

Then I will just concede that I have lost the last five months of new data. The unresolved issues with reports (ESPECIALLY the fact that there is no word about any pending solution) has made RMG8 impossible to continue with.

And with no adequate available means of making a smooth transition, I’ve just lost the data.

I’ve been with them since Family Origins was DOS-based, but this is taking much too long.

This is probably not the best time for me to offer to help but maybe I could migrate a substantial amount of your 5 months of work on RM8 to RM7. I’m not certain I can but there’s a new field in each table that registers when a record was last updated which may be of some help. I’d need copies of both your RM7 and RM8 databases.

@PatrickR I’ve developed a procedure that might acceptably marry your RM8 data with your RM7.5 custom reports, books along with the groups as they were at the time you committed your database to RM8. See:

Tom, thank you for the offer, but I’m just resigned to losing the changes I made in RMG8. I actually found a few of them, but I’ll do without the rest and hope I eventually catch them all up.

Every other time RMG has updated, the transition has been smooth, and I’ve moved up each time immediately (and I’ve been a customer since it was Family Origins in DOS). I should have been more cautious about making the switch this time.

The fact that my biggest problem is in reports, and that the problem seems to be dragging out interminably is the reason I moved back to 7.

Again, thanks for the offer, but I should just pick up SQL Lite and use it. I’ve done enough SQL coding in my working career (mostly PC databases, but also SQL Server), so it shouldn’t be hard. First time I followed a link, it seemed to start in the middle, and I’m also a bit lazy; just need to apply myself.

I wonder if you could elaborate a bit more about your unresolved issues with reports in RM8.

The last complete rewrite of RM was going from RM3 to RM4. I was very aggressive about about moving from RM3 to RM4 and later regretted it. I was actually pretty happy with RM4 for the first few months. Then it was time to produce a descendant narrative report for a family reunion, and I found that I couldn’t do it. The problem is that my reports for family reunions require a good bit of post processing with a word processor before printing. The RTF files produced by RM4 were so different from the RTF files produced produced by RM3 that my process for posting processing RTF files from RM3 wouldn’t work for RTF files from RM4. So I tried and failed to move from RM3 back to RM4. It simply wouldn’t work because the only solution was GEDCOM and far too much data was lost on the GEDCOM transfer. I finally had to develop a totally new way to post process RTF files from RM4 before printing them rather than going back to RM3.

As a result of that experience, I have been very cautious about moving to RM8. I’m still in production in RM7 but I probably spend more time working in RM8 than in RM7, trying to resolve all the problems I find in RM8. I think I’m getting closer to being able to move to RM8, but narrative reports are one of my many remaining problems.

My chief problem with RM8’s reports may sound pretty picayune, but it’s important to me. Namely, RM’s Descendant Narrative reports are missing some important vertical white space (blank lines). RM7 has excessive vertical white space in its Descendant Narrative reports, but it’s trivial to post process excessive vertical white space out of existence with a word processor. It’s not trivial to add the missing white space with a word processor because you have to chase down every single place where it’s needed.

Well, I also have a problem with RM8’s report viewer. It doesn’t have smooth scroll, which makes it very difficult to preview a report in RM8. The only practical way to preview an RM8 report is to save it as a PDF or DOCX and to view it there. And I always run a one generation Descendant Narrative report on any person I change, just to be sure my changes will look right in a report.

So I was curious about your report problems with RM8. Aside from the issues I’ve already mentioned (and aside from the Publisher feature still being missing in action), I actually find RM8’s reports pretty much ok. I do use RM’s Custom Reports pretty extensively, but only for one off type applications. I typically create a Custom Report, run it, and delete it. It’s usually easier just to create the Custom Report I need than to try to find an existing one in a list of dozens or hundreds of existing Custom Reports.

Jerry (or should I call you “The” for short? : - )


Up until now, I have updated RMG every time. and never had a problem, including RMG3 to 4. There are always a few bugs with the first release of a new version, but Bruce & Co. have always been great about assigning priority to the most critical ones and quickly fixing them. Version 8 has been the biggest single rewrite since moving from Family Origins into RMG (maybe even bigger than that), and has had more difficulties with its growing pains than any other one, and I’m still trusting them and not giving up, but I returned to RMG 7 until this particular issue is corrected before I move back up to 8.

The reports themselves are not a problem, and they are okay, if you don’t mind they employing the defaults shown in the image. The default is Times New Roman, 11 point (headings 14 point), while headers and footers are set at Veranda, 11 point. You can change these if you wish, but the database will not retain your changes; it will ALWAYS revert to those defaults. If you generate one report based on a certain criteria and then want to run it again under a different criteria, you start with the same factory defaults.

I regularly run a number of reports (Narratives, Family Group Sheets, Individual Summaries), and it rapidly became a real pain to have to reset the default font type and size each time I ran one – I don’t like Times New Roman, and I don’t like the header to be 11 point.

The worst thing is that I don’t know why this is. I’ve seen a few theories, but nothing that actually sounds reasonable. The new version came out late last year (late September) and the last upgrade was mid-March; I wish there was word about what the next update would be, and what has a place in line ahead of report fonts.