It sounds like you upgraded incorrectly. You should simply have opened the earlier version of your database with RM9 and it would have created the upgraded file without renumbering. I think you must have exporter a GEDCOM file from the earlier version and then imported it with RM9 with the ‘preserve numbering’ option disabled.
There’s no simple solution to restore the original numbers. Best to open the earlier version with RM9 and let it do the upgrade as designed. You will lose the work you’ve done in RM9 but maybe the File Compare tool will help you find it.
This is precisely what you, and many others, should NOT have done. The RIN number is something that should never have been exposed to users as it is used by the program internally. If you have a lot of people in which this has happened, it is pretty much going to be a manual task to correct. RM does come with a built in Reference No fact which is what should have been used from the beginning. using that fact, you can devise your own numbering system which will stay constant. Of course this is going to mean that you need to go back and manually change the cases that you have already numbered.
Looks like time consuming task but needs must. Annoyed at RootsMagic as you say this numbering system should not have been available to use.
Water under the bridge now, will have to devise my own number system. However, whichever number I use I will not see it when opening the database against each person.
Thanks for taking the time to explain problem to me.
I am not fully certain what you mean by this or how you are seeing things when you open your current database, but in the settings for RM, there is an option to display RIN, REFN or FSID for each person. RIN is what you currently are using. REFN will be what you enter when you add the Reference No fact to your people and FSID is the FamilySearch ID number.
The numbering that you currently have can still be used as can the RIN numbers of any new people you add. You just have to copy the RIN into the Reference No fact. There may still be a bit to sort out if any overlap between the old RINs and the new ones assigned after your import.
When I open RootsMagic there is a number to the right of the persons name. which I am used to, I guess I will get used to the new numbering.
I think the easiest way forward is the print out a list of all the people in the Database to see the proportion of people that have changed number from the original list and alter them all to REFN and then alter all my certificates.
Exactly what I am talking about, you can still have a number there if you change the settings to use the REF# instead of RIN, so you will still see your number, nothing changes in that regard except for where that number comes from.
I have changed to Reference Number, Ref#, However, I cannot see where the number is now. When I look at a person on the opening page there is no number. Am I missing something?
I agree, except that there still would need to be some sort of ID number that is exposed to the user, that is generated automatically, that is never changed by RM, that is unique to each person, that is supported in RM9’s search boxes, and that reliably survives a GEDCOM export/import and a drag and drop. WIthout such an ID, it’s very difficult to identify multiple people with the same names, as in the eternal question of whether duplicate spouses are really duplicate or whether there are just duplicate family links. The ID information is important when RM users are making decisions about unlinking vs. merging.
RM actually sort of has such a number. It’s called a Unique ID. But it’s not exposed to the user interface. It is a very long number and it is too profoundly ugly of a number to be used by RM users for things like filing paper and electronic records.
The Reference Number fact is not satisfactory for this purpose. On the good side, it is not changed automatically by RM and it survives a GEDCOM export/import and a drag and drop. But that’s not good enough.It is not assigned automatically. It is not unique because more than one person can have the same Reference Number and the same person can have more than on Reference Number. And it is not supported in RM9’s search boxes.
Thanks for your reply. It was updated from RM8 as far as I understand. I paid my money then went to the download I exported RM not sure what version to Family Search many years ago to a Gedcom but not the other way round.
From memory I clicked on a link after I purchased the update.
RootsMagic doesn’t offer phone support. Sounds like you googled and found a number to a different company that says they provide RM Support. That is why they wouldn’t be able to answer a basic question.
There really did have to have been a GEDCOM involved in the process somewhere along the line. Transitioning from RM7 to RM8 or from RM8 to RM9 or from RM7 to RM9 does not renumber RM’s ID numbers.
Another possibility is that there was a drag and drop of the entire database at some point. A drag and drop of an entire database does renumber RM’s ID numbers. You don’t see the GEDCOM with a drag and drop and you don’t do an export and an import with a drag and drop. But drag and drop does use GEDCOM as its transport mechanism and it does do an export and an import of the GEDCOM it uses for the transport.
For that reason, I think that RM needs some mechanism other than a drag and drop that can be used to clean up certain data problems in the RM database. Or at a bare minimum, drag and drop of an entire database needs to be able to preserve RM’s ID numbers. The option to preserve RM’s ID numbers does exist on a GEDCOM import if the database into which the GEDCOM is being imported is new and empty.
This is not good, I am trawling through the datebase at present to see how many of the Automatically generated numbers have survived the update. Then take it from there.
I am not certain what your opening page is as it could be one of several views. Here is my opening page, in Pedigree view. The number is to the right of the name in the upper left corner.
I disagree that anything should be automatically generated. I also disagree that it is “needed”. It is/would be convenient but it is not neccessarily needed. Multiple persons of the same name can still be determined and it is a good reminder that people need to pay closer attention to what they enter. I would almost bet my lottery winnings that half of the multiple people of the same name occur due to an oopsy on the user’s part. Not paying attention merging, entering sketchy data etc. I do understand and have experienced some issues that led to multiple persons who are really one. I have never in my life looked at the RIN numbers to settle it.
However, for those who can’t manage, then it sound like something similiar to the REF# is needed. Maybe call it UniqueID is something equally clever, then hid the RIN number and leve the current Reference No fact for people’s personal filing system.
Ah, you could be right I may well have used drag and drop at some stage.
I have 1068 people on my database, in your opinion which would be the best way to tackle this problem. Ideally, I’d like to keep the same numbers as I have at present, however, this may not be possible, I’d probably be quicker to leave the numbers and change the certificates.
I am rather concerned that RootsMagic in their next update might mess up the numbers again, do you think this is a possibility?
