Yes that’s what I have, which I can still see if I am have my numbers set at RIN. When I changed to Ref# setting, the numbers are no longer there.
Then it appears those people do not have REF# entered. Which is understandable unless you have manually transfered the RIN number into the Reference No fact for those people for whom you have certificates. Or unless you entered a Ref# in any other way.
Probably an easy way of looking through the file is to use the People List view. Make sure to click the Customize Button and add both Reference No and Rec No to the columns. You can then click on the column names to sort them and if you need to, you can double click a person’s name in order to add the Reference No fact.
I have been upgrading and using RM’s basic numbering system for years. On a gedcom, as has been already mentioned, there is a box to check to preserve record numbers. I have never had a problem with this. I like to keep the original numbers RM has assigned to individuals in my database, because it gives me an idea of when over a period of years I entered the information. But then I have almost 300,000 names and I began using a genealogy program with Family Origins which predated RM about 1995. When I merge, I plan to merge from the larger number to the smaller for that person. I also keep copies of one or two old databases on old computers that may be a couple years old. That way, if I make a mistake merging something I should not have merged, I can go back to see what things looked like before the merge. Believe me, we are all likely to make mistakes in merging and having those original RM assigned numbers can be a godsend.
For most of us, it would appear the most useful numbering system is the one RootsMagic set up in the first place. Most people starting out using a genealogy program would not be looking to create a different system. Until today’s thread I have never heard a reason offered not to use their system, unless one has a preferred system designed on that users unique needs.
The problem is that a user will encounter the problem if they use GEDCOM and fail to check the box, or if they use drag and drop where there is no box to check. Drag and drop is often recommended as the solution to data corruption in a database. Any user who follows this advice will have their database renumbered.
I think that it’s extremely unlikely that a future RM update will mess up the numbers again. The current RM update did not mess up the numbers, either.
What messes up the numbers is copying your database using GEDCOM export/import without checking the box on GEDCOM import to retain the numbers, or copying your database using drag and drop instead of using GEDCOM export/import to copy your database because drag and drop doesn’t have the box to check to retain the numbers.
Just a random comment- TMG has a PersonID that is assigned automatically, but is not a database key. It is changeable through the user interface and uniqueness is enforced.
It was exported via GEDCOM and RM used it for at least the first 1000 people when I imported. (For some reason, RIN’s took a big jump after ~1000)
I use RIN’s all of the time and I wish DB record numbers of the other database objects were also available through the UI (call it an “expert option”).
MRIN (Marriage record number) is the only other one available and only through a report, iirc.
I shudder to think how many “experts” we will see accessing the so-called “expert option” and massively horking their DB because they have no idea what they are doing. Such an option has been floated in the past and fortunately did not receive a warm welcome from the devs.
If you have some basic understanding of databases and SQL, you may even try to copy directly in the database. The database structure is not overly complicated and contains only about two dozen tables - but this task affects only about two or tree of them.
Alternatively, If you still have a copy of the old database, the old RINs could be extracted and inserted into the new database as a Ref #, provided some other elements of the records are unique enough for automatic matching.
I cannot stress enough: Please, don’t do any of the manipulations mentioned above in your original database - always work with a copy!
I was just suggesting that the database objects like source , citation, media file have their primary keys displayed like the RIN in name lists. Nothing more.
It helps troubleshooting because RM allows objects to be named with any string, including duplicates.
I have a reasonably decent knowledge of databases and SQL thanks to way too many years of working in development jobs and way too many years of college. Personally I couldn’t care one way or the other as I am not the original poster on this.
Just because I have this knowledge and you have this knowledge and about a dozen or two other people in this group have the knowledge, playing with SQL is NOT something that should even be suggested to people who do NOT have this knowledge, yet it is time after time. I was trying to avoid suggesting it on purpose.
1 Like
And I was suggesting that the existing RIN be buried to stop people from using it and then getting fussy when things change, or they delete someone from their database and now there are holes in the RIN sequence.
1 Like