Hello everyone, my first post.
My family tree (RM9) contains approximately 1700 individuals and I have tried to produce a Gedcom file to share with a cousin. When I follow the instructions I can see the file count increasing but when it reaches around 620 the program crashes, displays rows and rows of text including individuals names, freezes, and will not close without a reboot.
I have no problem producing a Gedcom file for a smaller tree of 160 individuals.
My laptop is an ASUS i5 processor, 16GB RAM, 2GB SSD, and x64 based processor, running Windows 11. Surely this spec is sufficient to produce a Gedcom file, or am I doing something wrong?
Any suggestions would be gratefully received.
don’t know what is happening but run the Tools and see if that helps. One option is to have them install RM Essentials (free) and send them your database. skip gedcom altogether
I suggest you submit a support ticket detailing the problem to the support team to investigate.
The computer is not at fault unless it is defective. Rather, your tree is corrupted, likely by a lineage loop (a person is his own ancestor). RM has no tool for the user to find that condition so submit your database file to RM Support.
Assuming that your SSD is 2 TB, not GB, it’s likely that there is some data corruption around person #620. GEDCOM exports are sorted by person ID, so if it stops there, it is quite likely that that person has some weird data or relations. I don’t know how to find a person by ID, but you may find other clues by looking for the 1st person displayed when the program freezes.
Running the database tools may also help.
I suggest that you make a backup first, by copying the .rmtree file to another folder.
Thank you for the responses. I have run the tools, as suggested, and it made no difference. I will try the export again and see if I can see which person it seems to fail on before passing it to Support.
I will report back.
What you can do is to open the .ged file with a text editor (Notepad or Notepad++, e.g.) and inspect the area at the end. That may give some clues. You could even copy the last few lines here. The last line starting with 0 @INDI …might represent the RIN of the last person to have been processed. I don’t recall if the number following that tag is the RM record number but I’m pretty sure it is, nor whether the order of export is in RIN order (you can confirm that by inspecting the order in which the 0 @INDI lines appear in the file). The problem might lie within that last exported person’s data or possibly the one with the next RIN.
I tried again and printed the report that was generated when it crashed/froze. I checked the individual listed and found a recurring reference for an image. I have removed that flaw, run the export again, and am pleased to report that the export completed.
Thank you all for such helpful responses. Wonderful.
I’m pleased the problem is solved, but it should not have crashed RM. If I were in your situation, I would make a copy of my database, reintroduce the flaw into the copy, make sure the flaw still crashes RM, and then submit my database with the flaw to RM for analysis. Hopefully, they will fix the bug in RM that is crashing RM when a database contains your flaw.
Just to be clear, your “flaw” is something you typed in that any user could have typed in. It is not some sort of disk corruption that’s outside of RM’s control. No data that a user can type in should ever crash a piece of software. If it does, that’s a bug, pure and simple. It’s not some sort of “it’s working as designed and don’t type the data in that way” sort of situation.