I have attempted several times to create a GEDCOM file from RM8. Each time it runs at a snail’s pace and shuts down not even half way through.
I AM NOT very impressed with RM8 at all!
I just tried this on my mac and it worked fine. Others have used a RM8 gedcom to recover their data and return to RM7.
Perhaps there is an issue in how you created your RM8 file. Try using the tools to fix problems or try importing a fresh RM7 or FTM gedcom or downloading an ancestry tree.
2 Likes
Save a backup copy with a name identifying it as suspect. Run Command Palette>Database Tools. Successively from top to bottom, click each button and let them run. Close all open databases, exit RM8 and restart the program. Now open the database that was giving problems, save a backup copy with a name identifying it as fixed and then try exporting a small(er) subset of folks first (as an experiment/test) and see if that finishes. If it doesn’t lock up the program, a larger export is in order. If it does lock up, restart RM8 and try exporting just one individual. If that fails, you’ll need to contact RootsMagic support and seek resolution advice.
2 Likes
Kevin’s advice is spot on. We’ve learned from previous versions of RM that a periodic full export including everything is a useful exercise of the database for mistakes (such as a lineage loop) that can cause the program to freeze or crash doing some specific thing. If you have the RM7 database from which your RM8 database was imported, a further suggestion is to do the export testing on it. If its full export crashes, then it is likely the same fault was imported and is causing your RM8 export to fail. In that case, you might well follow Kevin’s procedure on the RM7 database because the software is more reliable than RM8 which may introduce other errors that compound and confound the issue.
1 Like
BTDT did not work. Program still locks up
I find it sort of amazing that the first step mentioned in debugging a problem is to run database tools to “fix problems.” Does anyone have experience with other genealogy software that requires this degree of db maintenance?
Rich
1 Like
Yes, FTM strongly recommends doing so before a TreeSync. Both FTM and RM use the same database engine, SQLite, and both incorporate its Integrity Check, Reindex and Vacuum functions in their database tools. Under Rebuild Indexes, RM combines Reindex with its own table update of Birth and Death Years. I’m not aware of any other application processes under its Database Tools. FTM has a much more intensive data analysis (takes time) to suss out and suppress or fix data issues that can screw up TreeSync.
That said, the RM Database Tools are seldom really needed (except for the maintenance of the redundant Birth/Death Years values). It’s an easy straw to grab at when responding to a problem. Ah, but there’s one I omitted - Delete Phantoms. That’s an application cleanup of some things it left behind in previous operations because it doesn’t always properly clean up after itself.
In the context of an export failing, running the Database Tools is sound advice. It could be that there is database corruption in a location on the drive that was accessed for the first time in a while because of the full GEDCOM output.
1 Like
I’ve never seen decent desktop database software – and not just for genealogy – that didn’t have a set of tools for repairing it. Databases of any kind will hiccup occasionally. That’s just life. Just like I re-boot my computer every couple of days to flush the buffer, I also run the repair suite on my databases every week or two, just to keep everything tidy. It’s just part of the routine.
2 Likes
Emkay,
My point is that it shouldn’t be part of the routine. Sure, if your computer crashes in the midst of an update you need to do something to look for possible damage and repair it.
A good database program should include a lot of internal integrity checking. It should include journaling to facilitate rollback functionality (like Family Historian 7 does.). And the programming should be solid enough and the testing rigorous enough that bits and pieces of junk and bad pointers won’t be left cluttering up the db.
But I also understand the pressures that a small programming staff feels when trying to implement a new version, and the time constraints sometimes don’t allow for rigorous testing. RM has been under tremendous pressure from its user base to release v8. So much that they had to release a version without all the functionality of v7. Let’s hope that they can get all the fires put out and start releasing feature upgrades soon.
Just my observations from working in IT for over 40 years, many of them in database design and programming.
Rich
1 Like
FTM 2019 suggests doing a backup and then a deep inspection as part of compacting the database or before synching.
after adding a few people/media/sources to my computer file and before synching up to ancestry I compact/fix the file and usually get 0.5…1% compaction. This is a quick routine process like brushing your teeth. RM7-8 does this in a more clunky 4 step process and never tells you the results if any.
Most users expect a program to take care of itself and not require us to know an obscure language like SQL to get basic functionality out of it. FTM, Heredis and MacFamilyTree get this and the latter two also bundle all media into the database avoiding tyro mistakes on scattered media.
1 Like
Actually occasionally RM does (or at least did) tell you the results. I distinctly remember (in RM7) getting a result from the Test Integrity run that I was recommended to download to the Clipboard. It only happened once, and I’m afraid I can’t remember if I actually followed the recommendation.
This was using the Mac in a bottle version