- Using SQLite, you could convert a person's RIN to any unused RIN by editing the PersonTable and every reference to it in other tables. It is technically feasible, therefore, for the RM software to report unused RINs between 1 and the highest value used and to provide the user with a tool to select a person and assign a RIN. Even to select multiple people and have them reassigned RINs from the unused pool starting with the lowest. These would be enhancements.
- My comment about indexing was superficially written in haste but the point is that there is nothing systematic about its value in RootsMagic and it is totally reliant on the user. A user may have a 'system' but there is nothing to prevent that system from colliding or conflicting with some other 'system' when databases meet. I have two REFN systems in my main database containing the RINs of people as they were in the different databases inherited from two cousins, prefixed by a string that I recognise as identifying which cousin was the author. That allows me to crosscheck with their books and reports. One REFN was added using SQLite on a RM database imported from the original PAF. The other original file was not found after his death so I had to transcribe everything from his reports and added the REFN manually; of course there was nothing to preclude typos and duplicate values.
- When I explored this some years ago, it was always the earliest Ref Number fact added to a person (of those existing) that was displayed after the person's name. The Primary flag had no effect.
- For examples of some SQLite scripts operating on RootsMagic Reference Numbers see http://sqlitetoolsfo...ntent?tag=refno
Control over Record Numbers (RINs)?
Posted 14 January 2016 - 01:10 PM
Posted 14 January 2016 - 01:13 PM
My quick test seemed to show that the <order when first added> controls which is displayed if none are selected as primary
Does the Primary flag now control which is displayed?
Posted 14 January 2016 - 01:35 PM
For those folks that want to go the reference number route and who want to avoid duplicate reference number facts when there are duplicate reference numbers, you could just put both reference numbers on the same reference number fact - perhaps separated by a blank or a comma or a slash or something. Tom's example of two different sequences of reference numbers from two different databases inherited from cousins is a good example of where this could be valuable. Limiting yourself to one reference number fact per person also has advantages when doing searches with RM Explorer, when making the reference number fact into a column in People View, etc.
Posted 14 January 2016 - 02:02 PM
If the two reference numbers are in the same fact, and you choose to display the Reference number, both reference numbers will be displayed on the main screen and in reports. On RootsMagic Explorer, both the record number and reference number is printed.
I use a / to seperate multiple reference numbers in one Reference number fact. It is very visible as a divider.
Posted 14 January 2016 - 06:27 PM
1) thanks, have already done that and looked around at the data, and I'm studying the schema.
2) The numeric value associated with the INDI tag (0 @Ixxx@ INDI) is called an XREF.
Based on my statement in #2 the RIN used in RM is the GEDCOM XREF and this (as a database designer and expert) is a pointer, database key (aka foreign key) and should not be exposed to users, it should be maintained as an internal only value.
Yes an REFN tag can occur multiple times for an individual but if used correctly with a TYPE subtag can be unique or at least more unique than a sequential produced XREF that may or may not be maintained across imports or exports of a GEDCOM.
DeadEnds, keeping and maintaining the low numbered Record ID that is really a database key is, over time, not a valuable endever. The value if exported as a snippet from another database could be any value and not just a number, so systems could change the value if needed. Some systems do not even expose this value to the user and in the future you may loose your carefully numbered system. As your database grows and you include via collaborative databases, have a specific person as number 1 could be counter productive.
Posted 14 January 2016 - 06:41 PM
I actually use this in my system to identify persons by affiliation. This help to organize individuals by their affiliation to a family patriarch, or farm or other affiliation. The only person key that is unique is the TYPE "accession"
2 REFN 2012-12-0001
3 TYPE accession
2 REFN 15673
3 TYPE Naustal Farm
2 REFN 8359
3 TYPE Jonson Tree
Posted 14 January 2016 - 09:31 PM
I see that the GEDCOM RIN tag was added to GEDCOM 5.5 but the term "RIN" was commonplace, I believe, among genealogy softwares long before and, possibly, from their beginning. That common usage was exclusively associated with each individual and was probably in most systems the primary key for persons then as it is now in RM, else why was it called Record ID instead of Person ID. If it is not good design to expose the primary key, my guess is that it was pretty common in genealogy software and may still be. I'm unaware that RootsMagic has any support for the GEDCOM RIN tag for individuals unless it is essential to one of the GEDCOM flavours it does support. But GEDCOM RIN is optional while XREF:INDI is essential, so...
Also unsupported by RootsMagic is the REFN TYPE tag so I don't see how your suggestion re merging GEDCOM files can be of any help to a RootsMagic user. I don't know if it is supported by any other software.
Are there specific improvements to RootsMagic that you might request that would be beneficial to its users? You should post each under a unique topic in the RootsMagic Wishes forum.
Posted 14 January 2016 - 09:45 PM
Unfortunately the TYPE tag on any and all event/fact is very important to me. I use it extensively throughout my GEDCOM database. Do you know of a published document by RootsMagic that spells out the GEDCOM supported by RM? I also use many of the subtags of PLAC, ASSO, Source_Citation, Source_Repository_Citation and Note_Structure
Posted 14 January 2016 - 10:07 PM
Posted 14 January 2016 - 10:32 PM
No. RootsMagic writes a log of unrecognized GEDCOM lines in the same folder as the database to which the GEDCOM file was imported having the same name as the imported file but with the .LST extension. Inspect it with a text editor and review the reported line numbers in context in the GEDCOM file. If you import your 100% 5.5.1 file, the .LST will give you a first order idea of what is ignored and, inferentially, what is accepted. How RM processes the lines accepted can be answered by examination through the RootsMagic UI and its transparency by comparing its GEDCOM export to the original.
Do you know of a published document by RootsMagic that spells out the GEDCOM supported by RM?
Posted 14 January 2016 - 10:36 PM
I use nearly 100% v5.5.1 GEDCOM and have banged my head so many time with non-compliant files I've got permanent flat spots on my forehead.
What software do you use to interact with your GEDCOM?
Posted 15 January 2016 - 10:39 AM
I'm a programmer
Well, if you get interested in using RootsMagic seriously, maybe you would help develop user-friendly outboard utilities. I have created quite a few SQLite scripts but they are not accessible to the average person and I have bundled some into a more user-friendly application (RMtrix) but I am not a programmer - there is plenty of room for improvement!
Posted 15 January 2016 - 11:03 AM
... but I am not a programmer ....
I beg to differ. You may not be a programmer by profession - but you are a programmer, and an excellent one!