Is there a way to auto create a hyperlink at end of sentence (based on RIN #)
Such as “http://mysite.org/getperson.php?pid=[RIN]” Not sure if the RIN field is part of sentences.
Basically I want to create a link to by website for each person without having create a fact
thanks!
Kevin
There is no field or variable in the sentence template language for RIN.
http://wiki.rootsmagic.com/wiki/RootsMagic_8:Sentence_Template_Language#Fact_Sentence_Fields
What you might do is to set the default sentence for a Fact Type to include the hyperlink with your unsupported variable “[RIN]” and then use SQLite to customise every instance of that Fact Type, replacing “[RIN]” with the OwnerID from the same table.
You can add WebTag to a person, which doesn’t require a fact. Otherwise if you add a URL to a note it will create a hyperlink. You would need to supply the correct URL.
Is this still the case? The online docs seem to indicate so, but wanted to check.
I have so many people with the same Given-Surname that I want reports to refer to individuals as “Mark Whidby [5]”.
RIN is NOT a user-entered piece of data. It’s an indexed pointer to the user-entered piece(s) of data (assigned internally by the program) and is subject to change one or many times (potentially) depending on program operations applied to the database.
Mark Whidby [5] could become Mark Whidby [3] or Mark Whidby [7] and then… original reports would possibly refer to unintended individual(s). That is likely why it is not an option.
Got it, thanks. Any recommendations on how to uniquely identify individuals in reports?
Hey Mark
I definitely understand the problem of trying to keep people with the exact same names sorted–would be interested in what @thejerrybryan and others suggest also..
As Ken said RIN # can and will change – a REF # is a good idea since you are NOT that far along BUT for me it’s an impossible task with all m databases-- in just 2 of my Green files, I have 372 Greens in ours and 1371 ( only abt 8 of ours are in this database) in the other that contains a confirmed DNA cousin line plus a bunch of other Greens in the same counties who may or may not be related–so yes I have tons of guys with the same names born approximately the same time etc and they lived in the same and adjoining counties..
You could try making groups and color coding BUT I am afraid you Might run out of colors or too many would end up in the same group…
Having middle names and dates of birth / death help BUT not when you have that many-- in my younger days, I would add things to the name such as father’s name or where born county or state – and yes I can hear everybody throwing a fit abt that BUT it worked..
In my opinion, as far as using Mark Whidby [5] etc, I don’t see how it could change IF it’s part of the name BUT as I said if you only have less than 1000 people in the database, a Ref fact would be easy to add in a short amount of time
I don’t have any magic solutions to sorting out same name people without middle initials. It can be very hard.
I’m more and more using People List View as my go to way view my data in RM. I use it with groups as filters and with names as filters or with both as filters. I make sure I have birth and death dates and places as columns. That does help a lot. I also use the Family tab in the sidebar about 90% of the time. That also helps a lot because it’s a good way to see parents and spouses. It also means that for the most part I don’t have to use the main Family View.
It sure would be wonderful if I could have things like names of spouses or names of parents as columns in People List View. I have never added anything to names or suffixes like “son of Andrew” to make the distinctions clear when just looking at lists of names.
One of my more amusing stories is that at one point there were so many men in Sevier County, Tennessee named John Underwood and without middle initials that one of the tax lists had the same problem of telling all the John Underwoods apart. So the tax list mentioned “John Underwood the red head”. Of course, with me not knowing which of the many John Underwoods was the red head, that didn’t help me very much, aside from giving me a good laugh.
And of course this sort of problem extends beyond my own database. I have a fourth great grandfather in my database named Titus England. Titus was a common given name in the England family and so I have lots of Titus Englands in my database. My Titus England was born about 1787, died in 1841, and was married to a woman named Elizabeth (surname unknown). I have another Titus England in my database who was born about 1770, died in 1849, and was married to a woman named Elizabeth Stewart. My Titus England lived in Anderson County, Tennessee. The elder Titus England lived just across the county line in Roane County, Tennessee and then later moved to Missouri. There is a very high probability that the two men were related, but I don’t have any evidence for what that relationship might have been.
The users at FamilySearch keep merging the two Titus Englands and the two Elizabeths, no matter how many times I unmerge them and no how many warning messages I post in FamilySearch and no matter how much data I post in FamilySearch about why the two couples were not really the same couple. I suspect and cannot prove that the elder Titus England was the uncle of the younger Titus England. But even if I came up for evidence of that, it wouldn’t change the difficulty of telling them apart at a casual glance in my database. And it sure wouldn’t change the problem of FamilySearch users merging them even though they clearly are not the same men and even though I have very clearly flagged them as such.
I do make heavy use of color coding. That helps some. For example, right now the two Titus Englands are a different color, and that definitely does help. Besides color coding and showing the birth and death information in People List View, I’m not sure what else I can do.
Keyword ‘reports’:
-Color coding falls down for any b&w medium (non-color printers), but would work for PDF and onscreen .DOCX
-Groups may aid filtering for report inclusion, but not visual uniqueness.
-Middle names, Prefix/Suffix and Nicknames amidst accompanying relatives inform about the reported-on individual(s).
-Facts & Dates, particularly Association (Relative), Description (was described as can link relationships), Divorce/Engagement/Marriage/Namesake/Separation (hint at relationships)
