Getting at a WebTag for a Citation from the Edit Person screen takes many clicks and loses the big picture. If Citation WebTags were also accessible from the WebTags button on the Edit Person screen (and, hopefully, we will soon see this button also on the TimeLine View and RootsMagic Explorer), it would be much faster and the full picture of the person maintained. Ideally, RootsMagic would automatically populate the WebTags dropdown list with the citation WebTags. Until this enhancement is provided, a workaround is to create a duplicate of the citation WebTags for the person whose facts are supported by the citations.
For further consideration, whether to translate WebTags for Research Items on the person to WebTags for the person.
WebTags-DeleteDuplicates.sql Use if WebTags-Consolidate is repeated or there is other evidence of many duplicate WebTags.
-- WebTags-Consolidate.sql/*
2012-12-10 Tom Holden ve3meo
Generates a WebTag for the Individual from all WebTags attached to citations
of that Individual, the Family in which he/she is a spouse, all his/her events
and alternate names. This results in ready access to all the person's WebTags
from the button on the Edit Person screen.
URL Owner Type (0 = Individual, 3 = Source, 4 = Citation, 5 = Place, 15 = Research Item)
Citation Owner Type (0 = Personal, 1 = Family, 2 = Event, 7 = Alternate Name)
*/INSERTORREPLACEINTO URLTable
--- Citation WebTags ------ Person for citations of PersonsSELECTNULLAS LinkID,0AS OwnerType,
Cit.OwnerID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN
CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =0UNION-- Fathers for citations of familiesSELECTNULLAS LinkID,0AS OwnerType,
Fam.FatherID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN FamilyTable AS Fam
ON Cit.OwnerID = Fam.FamilyID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =1UNION-- Mothers for citations of familiesSELECTNULLAS LinkID,0AS OwnerType,
Fam.MotherID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN FamilyTable AS Fam
ON Cit.OwnerID = Fam.FamilyID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =1UNION-- Person for citations of individual eventsSELECTNULLAS LinkID,0AS OwnerType,
Evt.OwnerID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN EventTable Evt
ON Cit.OwnerID = Evt.EventID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =2-- Event citationAND Evt.OwnerType =0-- PersonUNION-- Husband for citations of Family eventsSELECTNULLAS LinkID,0AS OwnerType,
Fam.FatherID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN EventTable Evt
ON Cit.OwnerID = Evt.EventID
INNERJOIN FamilyTable Fam
ON Evt.OwnerID = Fam.FamilyID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =2-- Event citationAND Evt.OwnerType =1-- FamilyUNION-- Wife for citations of Family eventsSELECTNULLAS LinkID,0AS OwnerType,
Fam.MotherID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN EventTable Evt
ON Cit.OwnerID = Evt.EventID
INNERJOIN FamilyTable Fam
ON Evt.OwnerID = Fam.FamilyID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =2-- Event citationAND Evt.OwnerType =1-- FamilyUNION-- Person for citations of Alternate NamesSELECTNULLAS LinkID,0AS OwnerType,
Nam.OwnerID AS OwnerID,0AS LinkType,
URL.Name AS Name,
URL.URL AS URL,
URL.Note AS Note
FROM URLTable URL
INNERJOIN
CitationTable AS Cit
ON URL.OwnerID = Cit.CitationID
INNERJOIN NameTable Nam
ON Cit.OwnerID = Nam.NameID
WHERE URL.OwnerType =4-- Citation webtagAND Cit.OwnerType =7-- Alt Name citation--- End of Citation WebTags ----
;
A GEDCOM downloaded from Ancestry.com contains an URL in the Citation Comments pointing to the online source. Previously, in Ancestry.com and RootsMagic 5, I outlined a method to marry images automatically downloaded to a synchronised FamilyTreeMaker 2012 database with the citation URLs from the Ancestry GEDCOM in a common RootsMagic database. RootsMagic 6 introduced the WebTag which instantly links to online resources by passing to the default web browser the URL stored in the WebTag. WebTags can be added to any person, source, citation, place, or research log item. Wouldn’t it be great to get those URLs from the Citation Comments into WebTags for the citations!
The following query does a good job at creating a citation WebTag for each citation that has an URL in its Comments, with limitations:
The comment must begin with “https://” else it will be skipped.
If the comment contains more than the URL, the entire comment will go into the WebTag URL against which the browser will fail to connect; the URL will need to be edited.
These shortcomings can be largely or entirely overcome by high level programming, thus requiring an application to be developed or an extension created for SQLiteSpy.
The WebTag Name is taken from the citation’s Source Name while the WebTag Note is taken from the citation’s Research Notes.
A related query, WebTags – Consolidate, creates Person WebTags from Citation WebTags to consolidate all WebTags pertaining to a person under the WebTags button on the Edit Person Screen.
-- WebTags-MakeFromAncestryComments.sql/*
2012-12-10 Tom Holden ve3meo
Inspects for Citation Comments beginning with "https://" and generates
a corresponding WebTag. GEDCOMs downloaded from Ancestry.com have this
characteristic, typically followed by two linefeed-carriage returns that
are stripped by this query.
Due to limitations of SQLite, should the Comment contain more than the trailing
white space, the complete Comment is placed in the URL field and will
almost certainly fail to open the web page.
*/-- Make Citation webtags for Citation Comments starting with "https://"INSERTORREPLACEINTO URLTable
SELECT(SELECT LinkID FROM URLTable WHERE OwnerType=4AND OwnerID=Cit.CitationID)AS LinkID,4AS OwnerType,
Cit.CitationID AS OwnerID,0AS LinkType,
Src.Name AS Name,
SUBSTR(Cit.Comments,1,LENGTH(Cit.Comments)-4)AS URL,-- strip four bytes off the end, typ two pairs of CR-LF
Cit.ActualText AS Note
FROM CitationTable AS Cit
INNERJOIN SourceTable AS Src
USING(SourceID)WHERE Cit.Comments LIKE'https://%'
;
Work in progress. This query lists tasks related to Individuals, Families (Father’s name only outputted) and General research. Check it out and see if it’s useful. You can run it on the same database as RM4 is using (at your own risk) to assist finding tasks in RM4 or people to work on; alternatively, make a copy of the database to run your queries against. You can export the results to a spreadsheet for further massaging.
I’ve discussed this query before, but this is my first attempt to post a real, live query in both MS Access and SQLite formats. At the present time, my To Do grid only includes 17 rows and 2 columns but I will be adding additional rows and additional columns. I should mention up front that this query does not use RM4’s To Do list feature in any way. It establishes To Do items in a different way.
The rows in the grid correspond to individuals in my RM4 database, and at the present time I have 17 individuals who are of active research interest. The list of individuals who are of active research interest will grow quickly. The list of individuals of active research interest is maintained as a Named Group in my RM4 database. If I add individuals to that named group, those individuals immediately show up in my query. I hardwired group #6 into my query rather than hardwiring the name of the group into my query because it’s easier to deal with numbers in a way that’s compatible between MS Access and SQLite than it is to deal with text strings. Indeed, my query started out by using a text string to reference the name of the group, but it was just too clumsy keeping the MS Access and the SQLite versions of the query in sync, so I switched to the group number rather than the group name.
The columns in the grid correspond to items from my own personal To Do list. These are items that are not very amenable to tools such as RM4’s own To Do list or to the automated tools provided by GenSmarts. Most of my personal To Do items have to do with getting my database in good enough shape that a narrative report produced by RM4 is as nearly camera ready as possible, and that such a report needs little or no additional editing with a word processor before publishing. The first column is labeled PrgraphOk, and if it is checked off that means that I have verified that all my notes end with the appropriate carriage returns (or not) to producing the paragraphing that I want to see in a narrative report. The second column is labeled CensusOk, and if it is checked off that means that I have verified that all my census facts print out as I wish them to do – sentence templates are what I want and the fact notes are what I want. I primarily use GenSmarts as my To Do list to be sure that I get the 1850 census for John Doe who was born in 1845 and died in 1905, for example. So my To Do item of CensusOk is related only to how the census facts print out, and to be sure that they are camera ready.
I started out with the idea of storing my PrgraphOk and my CensusOk items in an MS Access table that would be joined with my RM4 database. But I later decided that I wanted RM4 to be my one and only official record, so I’m storing the information directly in RM4. I chose to use the existing Reference Number fact. After verifying that my To Do item is done, I then add facts to RM4 such as Reference Number PrgraphOk or Reference Number CensusOk. My query is robust enough that the PrgraphOk and CensusOk items can be entered on the same Reference Number fact or on separate Reference Number facts.
The design of the query is basically (list of individuals in the group) LEFT JOIN (list of individuals with the required Reference Numbers). Essentially, group membership constitutes the To Do list and the Reference Numbers constitute the To Done list. I don’t print the Reference Numbers in any reports, nor do I export them in any GEDCOM. The Reference Number facts are just for my own internal use.
Here is the query for SQLite.
SELECT L.RecNo AS RecNo, L.Surname AS Surname, L.Given AS Given, R.PrgraphOK AS PrgraphOK, R.CensusOk AS CensusOk
FROM(SELECT
N.OwnerID AS RecNo,
N.Surname COLLATE NOCASE AS Surname,
N.Given COLLATE NOCASE AS Given
FROM
GroupTable AS G,
NameTable AS N
WHERE N.NameType=0AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6)AS L
LEFTJOIN(SELECT
E.OwnerID AS RecNo,MAX(CAST(E.Details AS TEXT)LIKE'PrgraphOk')AS PrgraphOk,MAX(CAST(E.Details AS TEXT)LIKE'CensusOk')AS CensusOk
FROM
EventTable AS E
INNERJOIN
FactTypeTable AS F ON E.EventType=F.FactTypeID
WHERE F.FactTypeID=35GROUPBY E.OwnerID
)AS R ON R.RecNo = L.RecNo
ORDERBY Surname, Given
Here is the query for MS Access.
SELECT L.RecNo AS RecNo,LEFT(L.Surname,50)AS Surname,LEFT(L.Given,50)AS Given, R.PrgraphOK AS PrgraphOK, R.CensusOk AS CensusOk
FROM(SELECT
N.OwnerID AS RecNo,
N.Surname AS Surname,
N.Given AS Given
FROM
GroupTable AS G,
NameTable AS N
WHERE N.NameType=0AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6)AS L
LEFTJOIN(SELECT
E.OwnerID AS RecNo,MAX(Abs(StrConv(E.Details,64)LIKE"*PrgraphOk*"))AS PrgraphOk,MAX(Abs(StrConv(E.Details,64)LIKE"*CensusOk*"))AS CensusOk
FROM
EventTable AS E
INNERJOIN
FactTypeTable AS F ON E.EventType=F.FactTypeID
WHERE F.FactTypeID=35GROUPBY E.OwnerID
)AS R ON R.RecNo = L.RecNo
ORDERBY Surname, Given
Here is some further discussion of the scripts.
MS Access does not support comments. SQLite does. At the present time, my comments therefore will be narrative such as this which is outside the SQL script. This is not good programming practice, but it feels enforced upon me by MS Access.
In the outer SELECT statement, the Left function is used in MS Access for the sole purpose of making the columns sortable as a part of the MS Access filtering mechanism. I believe that it is the RMNOCASE problem that makes this necessary. The results of the SQLite query are not filterable and sortable after the fact, anyway. With the SQLite approach, all filtering and sorting has to be included in the body of the SQL. But MS Access supports filtering and supporting of the results of the query.
SQLite requires COLLATE NOCASE for columns that are text strings in the first sub-query. This is a part of the RMNOCASE problem. If you run the inner SELECT as a free standing query rather than as sub-query, the COLLATE NOCASE is not required. I’m not sure of the proper language to describe the problem, but it’s like passing subroutine or function arguments work in some programming languages, and the RMNOCASE values from the inner SELECT cannot be passed out to the outer SELECT without first removing the RMNOCASE characteristic.
In the second sub-query, MS Access uses StrConv to gain access to the content of a BLOB and SQLite uses CAST to gain access to the contents of a BLOB. MS Access uses double quotes, and SQLite uses single quotes. In MS Access, the LIKE operator won’t find my character strings unless I precede and follow them with * as a wild card character, and SQLite won’t work with the * as a part of the string.
MS Access returns -1 for true and 0 for false on a compare. SQLite returns 1 for true and 0 for false. So with MS Access I used absolute value to convert -1 to 1.
The maximum function (the name of the function is MAX) is used in association with the GROUP BY operator to allow PrgraphOk and CensusOk to be specified on the same or different Reference Number facts. And in association with the fact that the two sub-queries are connected with a LEFT JOIN, the query works correctly, showing blanks for the PrgraphOk and CensusOk fields for everybody in the group even when the Reference Number fact is omitted completely.
I would much prefer to show blanks for “not completed” and an X for “completed”, rather than 0 and 1. But I couldn’t find any way to do so that would work for both MS Access and for SQLite. The basic problem is that MS Access doesn’t seem to support CASE or anything like CASE. There are numerous examples of CASE on the Internet for MS Access, but I couldn’t get any of them to work.
I hard coded the Reference Number fact as fact #35 for the same reason I hard coded my group as group #6.
This problem is pretty subtle, but it drove me crazy for a long time. I would have preferred not having text columns such as Surname and Given appearing in sub-queries at all, given the RMNOCASE and other problems with text columns. I would have preferred just having the text columns appearing as a part of the very original SELECT. And indeed, there is nothing in the sub-queries that needs any text columns. But keeping Surname and Given only in the main SELECT would have meant a three way JOIN (something JOIN something else JOIN still something else) rather than a two way JOIN because I would have had to JOIN the NameTable with the two sub-queries. But the MS Access way of doing JOINS of three items or more is very different than the SQLite way of doing JOINS of three items or more. Both MS Access and SQLite will only associate multiple JOINS from the left. So far, so good. But MS Access insists that the multiple JOINS include appropriate parentheses, even though there is only one way it will allow the parentheses to be placed – namely the placement of the parentheses must correspond to associating the multiple JOINS from the left. And SQLite insists that the parentheses not be there. (By associating from the left, in math the equivalent is (x+y)+z for the left and x+(y+z) for the right). If that’s all there was to it, I would probably just add and remove the parentheses as required in switching back and forth between MS Access and SQLite. But when you add and remove the parentheses to reflect the left-to-right association of the JOIN’s as being explicit with parentheses vs. implicit without the parentheses, the physical placement of the ON clauses also has to change. So I’m trying to formulate all my queries not to require more than one JOIN of two items within any particular query or sub-query. For this particular query, the only way I could think of to do so was to have text columns in one of the sub-queries that got passed back out to the main query. Oh, the joys of SQL standards (not!).
Here’s the way my report looks at the present time in MS Access. The report looks substantially the same with an SQLite manager such as SQLiteSpy.
Jerry
Added 7/29/2011
Here is a slightly modified version of the query for MS Access. It uses the IIF function to convert the 1’s and 0’s into X’s and blanks. IIF is another one of those non-standard MS Access features that make it difficult to create a query compatible between various versions of SQL. I’ve also added additional individuals to the named group for the list of individuals of active research interest, and I’ve added additional columns. I’ve been calling the columns a “to do list”, but I think that it would be more appropriate to call them a checklist.
SELECT
L.RecNo AS RecNo,LEFT(L.Surname,50)AS Surname,LEFT(L.Given,50)AS Given,
R.PrgraphOK AS PrgraphOK,
R.CensusOk AS CensusOk,
R.ObitOk AS ObitOk,
R.SourceOk AS SourceOk,
R.TombStoneOk AS TombStoneOk,
R.SSDI_Ok AS SSDI_Ok
FROM(SELECT
N.OwnerID AS RecNo,
N.Surname AS Surname,
N.Given AS Given
FROM
GroupTable AS G,
NameTable AS N
WHERE N.NameType=0AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6)AS L
LEFTJOIN(SELECT
E.OwnerID AS RecNo,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*PrgraphOk*"))=1," X",NULL)AS PrgraphOk,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*CensusOk*"))=1," X",NULL)AS CensusOk,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*ObitOk*"))=1," X",NULL)AS ObitOk,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*SourceOk*"))=1," X",NULL)AS SourceOk,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*TombstoneOk*"))=1," X",NULL)AS TombstoneOk,
IIF(MAX(Abs(StrConv(E.Details,64)LIKE"*SSDI_Ok*"))=1," X",NULL)AS SSDI_Ok
FROM
EventTable AS E
WHERE
E.EventType=35GROUPBY
E.OwnerID
)AS R ON L.RecNo = R.RecNo
ORDERBY L.Surname, L.Given
Here’s a screen shot of the query when it is run against my live RM4 database.
When I ran the RootsMagic 4 Statistics List report on my database, I was startled by the stat for Maximum marriages per person – 7 for one or more males! That did not seem right for my genealogy – maybe it was a merging artifact. What if there were others with 7, or 6 or 5 – all of which would be suspect. I could not find which person(s) had so many spouses using RM4, short of running the Marriage List report and inspecting it. For a very large database, this would be hit or miss and slow. So I wrote this simple query to list the persons with multiple spouses. You can use the RIN of persons that bear further investigation to find them in RootsMagic and resolve any problems. In my case, the person with 7 spouses was *Unconnected Research Trees, a method that Laura described to collect loose persons in the database for further investigation.
Sharing of facts was a new feature added with RootsMagic 4. A Person or Family in the database (a Principal) is now able to share a fact with others either in a tree in the database file by linking to them or with those not in a tree in the file by indicating name only. Those people sharing the event with the Principal are each assigned a role in that fact/event.
Reporting and other capabilities within the program relative to shared facts haven’t yet been fully developed, and there’s currently no way to produce information relating to those not in a tree in the file (as of current version RM 4.0.7.1). However, the following SQL code can be run against the database in order to obtain that information, as well as relevant fact and Principal data: FactsSharedWithTreelessPersons-OO.sql Download this variant compatible with OpenOffice Base when used in Run SQL Direct mode. – includes these people in Report > Lifelines of a principal.
Script below is compatible with RM4- #RM7 and #RM8
-- People Who Share A Fact with a Principal, But Who Are Not in a Tree in The File List-- created by romermb on 26 Feb 2010-- Individual FactsSELECT WitnessTable.Surname COLLATE NOCASE AS Surname,
WitnessTable.Suffix COLLATE NOCASE AS Suffix,
WitnessTable.Prefix COLLATE NOCASE AS Prefix,
WitnessTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,NULLAS MRIN,
NameTable.OwnerID AS RIN1,
NameTable.Surname COLLATE NOCASE AS Surname1,
NameTable.Suffix COLLATE NOCASE AS Suffix1,
NameTable.Prefix COLLATE NOCASE AS Prefix1,
NameTable.Given COLLATE NOCASE AS Given1,NULLAS RIN2,NULLAS Surname2,NULLAS Suffix2,NULLAS Prefix2,NULLAS Given2
FROM WitnessTable
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN NameTable ON
EventTable.OwnerID = NameTable.OwnerID
WHERE WitnessTable.PersonID =0AND EventTable.OwnerType =0AND
NameTable.IsPrimary =1UNIONALL-- Family FactsSELECT WitnessTable.Surname COLLATE NOCASE AS Surname,
WitnessTable.Suffix COLLATE NOCASE AS Suffix,
WitnessTable.Prefix COLLATE NOCASE AS Prefix,
WitnessTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,
FamilyTable.FamilyID AS MRIN,
NameTable1.OwnerID AS RIN1,
NameTable1.Surname COLLATE NOCASE AS Surname1,
NameTable1.Suffix COLLATE NOCASE AS Suffix1,
NameTable1.Prefix COLLATE NOCASE AS Prefix1,
NameTable1.Given COLLATE NOCASE AS Given1,
NameTable2.OwnerID AS RIN2,
NameTable2.Surname COLLATE NOCASE AS Surname2,
NameTable2.Suffix COLLATE NOCASE AS Suffix2,
NameTable2.Prefix COLLATE NOCASE AS Prefix2,
NameTable2.Given COLLATE NOCASE AS Given2
FROM WitnessTable
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN FamilyTable ON
EventTable.OwnerID = FamilyTable.FamilyID
LEFTOUTERJOIN NameTable AS NameTable1 ON
FamilyTable.FatherID = NameTable1.OwnerID
LEFTOUTERJOIN NameTable AS NameTable2 ON
FamilyTable.MotherID = NameTable2.OwnerID
WHERE WitnessTable.PersonID =0AND EventTable.OwnerType =1AND
NameTable1.IsPrimary =1AND NameTable2.IsPrimary =1ORDERBY1,2,3,4,5,6,9,10,11,12,14,15,16,17
Discussions & comments from Wikispaces site
ve3meo
Nomenclature
ve3meo
27 February 2010 01:36:59
Another good query!
I wonder, ‘tho’, if the language could be a little more precise. There is no word ‘sharee’ but there is ‘sharer’. These Fact or event sharers not currently reported by RM are in the file and in the database but are not persons in the database trees. A more accurate name would be ‘List Fact Sharers not in Database Trees – Query’ and the description could be made clearer by revising accordingly.
romermb
romermb
01 March 2010 20:11:57
I actually intentionally used the same terminology used in RM4 in the Edit shared event screen — This person is not in my file.
Sharee (vs. Sharer) was used to try to differentiate the person sharing in the fact (vs. the one sharing the fact). However, I just looked and realized that it’s not an actual word! I was unable to find it in the dictionary.
Anyway, I grant that the wording could be made better, so will look to improve upon it here shortly.
Sharing of facts was a new feature added with RootsMagic 4. A Person or Family in the database (a Principal) is now able to share a fact with others either in a tree in the database file by linking to them or with those not in a tree in the file by indicating name only. Those people sharing the event with the Principal are each assigned a role in that fact/event.
Reporting and other capabilities within the program relative to shared facts haven’t yet been fully developed (as of current version RM 4.0.7.1). However, the following SQL code can be run against the database in order to obtain that information, as well as relevant fact and Principal data:
-- People Who Share A Fact with a Principal List-- created by romermb on 10 Mar 2010-- Individual Facts, Person Sharing Fact in Tree in FileSELECT WitnessTable.PersonID AS RIN,
NameTable.Surname COLLATE NOCASE AS Surname,
NameTable.Suffix COLLATE NOCASE AS Suffix,
NameTable.Prefix COLLATE NOCASE AS Prefix,
NameTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,NULLAS MRIN,
NameTable1.OwnerID AS RIN1,
NameTable1.Surname COLLATE NOCASE AS Surname1,
NameTable1.Suffix COLLATE NOCASE AS Suffix1,
NameTable1.Prefix COLLATE NOCASE AS Prefix1,
NameTable1.Given COLLATE NOCASE AS Given1,NULLAS RIN2,NULLAS Surname2,NULLAS Suffix2,NULLAS Prefix2,NULLAS Given2
FROM WitnessTable
LEFTOUTERJOIN NameTable ON
WitnessTable.PersonID = NameTable.OwnerID
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN NameTable AS NameTable1 ON
EventTable.OwnerID = NameTable1.OwnerID
WHERE WitnessTable.PersonID <>0AND EventTable.OwnerType =0AND
NameTable.IsPrimary =1AND NameTable1.IsPrimary =1UNIONALL-- Family Facts, Person Sharing Fact in Tree in FileSELECT WitnessTable.PersonID AS RIN,
NameTable.Surname COLLATE NOCASE AS Surname,
NameTable.Suffix COLLATE NOCASE AS Suffix,
NameTable.Prefix COLLATE NOCASE AS Prefix,
NameTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,
FamilyTable.FamilyID AS MRIN,
NameTable1.OwnerID AS RIN1,
NameTable1.Surname COLLATE NOCASE AS Surname1,
NameTable1.Suffix COLLATE NOCASE AS Suffix1,
NameTable1.Prefix COLLATE NOCASE AS Prefix1,
NameTable1.Given COLLATE NOCASE AS Given1,
NameTable2.OwnerID AS RIN2,
NameTable2.Surname COLLATE NOCASE AS Surname2,
NameTable2.Suffix COLLATE NOCASE AS Suffix2,
NameTable2.Prefix COLLATE NOCASE AS Prefix2,
NameTable2.Given COLLATE NOCASE AS Given2
FROM WitnessTable
LEFTOUTERJOIN NameTable ON
WitnessTable.PersonID = NameTable.OwnerID
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN FamilyTable ON
EventTable.OwnerID = FamilyTable.FamilyID
LEFTOUTERJOIN NameTable AS NameTable1 ON
FamilyTable.FatherID = NameTable1.OwnerID
LEFTOUTERJOIN NameTable AS NameTable2 ON
FamilyTable.MotherID = NameTable2.OwnerID
WHERE WitnessTable.PersonID <>0AND EventTable.OwnerType =1AND
NameTable.IsPrimary =1AND NameTable1.IsPrimary =1AND NameTable2.IsPrimary =1UNIONALL-- Individual Facts, Person Sharing Fact Not in Tree in FileSELECTNULLAS RIN,
WitnessTable.Surname COLLATE NOCASE AS Surname,
WitnessTable.Suffix COLLATE NOCASE AS Suffix,
WitnessTable.Prefix COLLATE NOCASE AS Prefix,
WitnessTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,NULLAS MRIN,
NameTable.OwnerID AS RIN1,
NameTable.Surname COLLATE NOCASE AS Surname1,
NameTable.Suffix COLLATE NOCASE AS Suffix1,
NameTable.Prefix COLLATE NOCASE AS Prefix1,
NameTable.Given COLLATE NOCASE AS Given1,NULLAS RIN2,NULLAS Surname2,NULLAS Suffix2,NULLAS Prefix2,NULLAS Given2
FROM WitnessTable
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN NameTable ON
EventTable.OwnerID = NameTable.OwnerID
WHERE WitnessTable.PersonID =0AND EventTable.OwnerType =0AND
NameTable.IsPrimary =1UNIONALL-- Family Facts, Person Sharing Fact Not in Tree in FileSELECTNULLAS RIN,
WitnessTable.Surname COLLATE NOCASE AS Surname,
WitnessTable.Suffix COLLATE NOCASE AS Suffix,
WitnessTable.Prefix COLLATE NOCASE AS Prefix,
WitnessTable.Given COLLATE NOCASE AS Given,
RoleTable.RoleName COLLATE NOCASE ASROLE,
FactTypeTable.Name COLLATE NOCASE AS Fact,
FamilyTable.FamilyID AS MRIN,
NameTable1.OwnerID AS RIN1,
NameTable1.Surname COLLATE NOCASE AS Surname1,
NameTable1.Suffix COLLATE NOCASE AS Suffix1,
NameTable1.Prefix COLLATE NOCASE AS Prefix1,
NameTable1.Given COLLATE NOCASE AS Given1,
NameTable2.OwnerID AS RIN2,
NameTable2.Surname COLLATE NOCASE AS Surname2,
NameTable2.Suffix COLLATE NOCASE AS Suffix2,
NameTable2.Prefix COLLATE NOCASE AS Prefix2,
NameTable2.Given COLLATE NOCASE AS Given2
FROM WitnessTable
LEFTOUTERJOIN RoleTable ON
WitnessTable.ROLE= RoleTable.RoleID
LEFTOUTERJOIN EventTable ON
WitnessTable.EventID = EventTable.EventID
LEFTOUTERJOIN FactTypeTable ON
EventTable.EventType = FactTypeTable.FactTypeID
LEFTOUTERJOIN FamilyTable ON
EventTable.OwnerID = FamilyTable.FamilyID
LEFTOUTERJOIN NameTable AS NameTable1 ON
FamilyTable.FatherID = NameTable1.OwnerID
LEFTOUTERJOIN NameTable AS NameTable2 ON
FamilyTable.MotherID = NameTable2.OwnerID
WHERE WitnessTable.PersonID =0AND EventTable.OwnerType =1AND
NameTable1.IsPrimary =1AND NameTable2.IsPrimary =1ORDERBY2,3,4,5,6,7,10,11,12,13,15,16,17,18
Discussions & comments from Wikispaces site
weaberj
Add date field to query
weaberj
17 May 2011 18:53:51
I have been using the query “People Who Share A Fact with a Principal List” for data entry checking for shared events. I find it very useful except for one field which is, at least for my purposes, missing. That field is the date of the event. One parent or couple can share several censuses with a child and while all are listed in the query results it would be a lot easier if the date were also there. I would modify the query myself except it does not query the event table which contains the fact date and I’m not sure how to construct the correct links. If anyone has some spare time (ha, ha) and can add the date, well, that would be great.
Thanks, John Weaber [email protected]
ve3meo
ve3meo
18 May 2011 12:01:18
If you are content with the raw date data, it is probably not a big deal to add a date column; decoding the raw data into more human readable form is. You can see what’s involved on the Date Decoder page. I wonder if one of the Lifelines queries might answer your needs – they include decoded dates and shared events. Copy and paste results into Excel or Calc and you can sort and filter.
Tom
microzoa
Thanks
microzoa
08 January 2012 16:46:13
Just a short word of thanks – this query is perfect for what i need. Thanks for taking the time. Hopefully I can add to the list at some point.
ve3meo
ve3meo
08 January 2012 18:37:38
Romer authored this query and I am sure he shares my appreciation for your word of thanks. His query found its way into several other more complex ones.
Feel free to contribute to the wiki something you have come up with at anytime. The more, the merrier!
Paragraph control in the narrative reports in RootsMagic 4 and 5 leaves much to be desired. A richly facted person with many notes will be described in one long paragraph, apart from any paragraphing within the body of a fact note, unless special non-intuitive measures are taken. Likewise, another long paragraph of family facts and notes follows.
Different folks have tried different strategies with varying success. Basically, there are two:
Use the Customize Sentence feature for Facts in the Edit Person screen and enter double Carriage Return/Line Feeds (the Enter key or Ctrl-M in the editor) at the beginning of the sentence of the fact for which you want to start a new paragraph (often after a long note from the preceding fact).
Add double CR/LFs at the end of notes of facts following which you want the next fact sentence to be in a new paragraph.
In both cases, one is likely going to want to do further paragraphing touch-ups in Microsoft Word on the RTF file saved from the RM Report Viewer. Also, the first creates new paragraphs even if notes are excluded from a report; that may not be wanted. The second does not survive a transfer; trailing white-space in notes is truncated on a GEDCOM export or drag’n’drop transfer between RM databases.
Until RootsMagic provides better control of paragraphing and persistence through export and transfer, it is desirable to have some batch process that can quickly provide a first cut at paragraphing reasonably. This page and its queries attempt to provide such tools.
Paragraph-strip.sql This query strips out leading and trailing CR/LF and blank spaces from the custom fact sentences and fact notes for persons and families. Execute it repeatedly until you think you have stripped out prior paragraphing. Twice should be enough if there was never more than two pairs of CR/LF entered at the beginning of a custom sentence or at either the beginning or end of a fact note. Paragraphing within the body of a note is unaffected.
Paragraph-add.sql This query so far addresses only paragraphing of person facts. It adds double CR/LFs at the end of each non-empty fact note and then attempts to strip them from the last note before the beginning of the family notes or children.It’s largely untested – feedback invited. If the Person facts are paragraphing as intended, then the same strategy may work with family notes leading to the spouse and child list.
(
Added by Jerry, 12/23/2011). I have done some testing of some of the items in Paragraph-strip.sql. For now, I’m focusing on the General (Individual) Note only. The SQL that I tested ran just fine. I have now run it in a small test database, in a copy of my production database, and in my production database. Using the SQL scripts saved me many, many hours of very tedious and error prone work.
The only little white space glitch I found was that in addition to blanks and CR/LF sequences, I found some leading TAB characters at the front of a few notes (CTL-I or X”09″). These were introduced into my database via GEDCOM import over a decade ago, before I really knew what I was doing in managing my database. I would have eventually found and cleaned them up anyway, but Paragraph-strip.sql greatly facilitated the process. In the meantime, here’s a very simple little query that I ran to monitor the progress of the changes I was making with SQL from Paragraph-strip.SQL. That’s how I found the TAB characters. I used an equivalent query to monitor changes on the right end of the notes.)
Jerry
)
SELECT P.PersonID,
HEX( SUBSTR(P.Note,1,1) ) AS LeftEndH1,
P.Note
FROM
PersonTable AS P
WHERE LENGTH(P.Note) > 0
ORDER BY LeftEndH1, P.Note
Discussions & comments from Wikispaces site
texas-nightowl
Italics in the fact notes
texas-nightowl
05 April 2016 22:19:44
paragraph-strip.sql : This is only the 2nd sql script I have attempted to run. Mostly, it worked fine. However, I had several notes for which it did not work, even after running it several times. The one thing all these notes had in common? They were italicized. So I exported to gedcom and took a look. And sure enough, the line feeds were before the ending <i>. I don’t remember whether I added the line feeds first and then italicized or whether I italicized first and then added the line feeds. But one way, or possibly both, the line feeds ended inside the italicize code and therefore the script considered the line feeds as part of the body of the note and the strip did not work. I don’t know enough to know if there is a way around that or not. Luckily, this was isolated (so far!) to about 6 people, so it wasn’t terribly hard for me to just edit the notes manually. So, just a heads up about that.
On integrating these queries into the RMtrix bundled utilities, I found it necessary to revise them extensively, partly because they do not safely or efficiently address those orphaned Place Details that are actually used by a fact/event in the database. Moreover, without the foreknowledge of the names of the Place Details, it is impossible to find them using RootsMagic tools. My revised queries provide both an efficient way of finding where the orphaned sites are used, so that we can get at them with the Edit Person screen, and a speedy deletion of only those that are unused.
Screenshot from RMtrix of results from the OrphanedPlaceDetails query. The unused ones have blanks for Person and Fact; the used ones can be readily fixed by using RM5 to edit the fact for the person shown.
FAQ
What is an Orphaned Place Detail? It’s a Place Detail for which there is no parent Place in the PlaceTable.
What’s the problem with them? Unused ones merely clutter up one table. While ones that are used do appear to come out alright in narrative reports, they do not show in the Place List, they cannot be: edited, have images tagged to them, geotagged nor commented.
How do they arise in the first place? One way for certain is that a Place Detail can be added through the Edit Person screen with the Place field left empty (as of RM5021). Other possibilities are from past deletion or merging of the parent.
How do I fix the ones I want to keep? Use the OrphanedPlaceDetails query in RMtrix or download and run it in SQLiteSpy to get the report. Using RootsMagic, select the persons listed and find the fact in their Edit Person screen; assign the Place and then add the Place Detail.
How do I get rid of the unused ones? Orphaned Place Details – Delete Unused in RMtrix or download and run it in SQliteSpy. WARNING – there is risk of database corruption of the sort that RM5 can repair but RM4 cannot. After the deletion, use RM5’s Database Tools > Rebuild Indexes. Best to leave the unused Place Details alone in RM4.
I’ve discovered that I have four Place Details in my database without a Place.RMGC_Properties – Query The situation can be identified with the following extremely trivial query.
SELECT*FROM PlaceTable
WHERE PlaceType =2AND
MasterID =0
PlaceType = 2 identifies PlaceTable entries that are for Place Details, and if PlaceType = 2 then MasterID identifies the associated Place with which the Place Details are associated. MasterID=0 indicates that there is no Place associated with the Place Details.
[Inline comment: ve3meo Jan 30, 2012 RMGC_Properties – Query flags all unused Place Details, including those with no master Place, in the row “-Unused Place Details”. However, it does not report a Place Detail used in a fact but lacking a master Place as that may be a legitimate use. For example, the Occupation fact – we might know that he worked at General Motors but not in which municipality. I suggest you run this query as you might discover some other surprises. It needs work to update the Media reporting to RM5.
]
For each of the four Place Details in question, I did a search within RM5 itself for “Any Fact Place Details contains (the Place Details in question)”. In three cases, nothing was found. In the fourth case, RM5 itself found the Place Details in question associated with a blank Place (basically, an impossible situation).
I have not run any of Tom’s Place/Place Details queries against my database. Whatever strange thing happened to my database just happened between me doing data entry with the keyboard and mouse and then with whatever processing RM4/RM5 did behind the scenes. I include both RM4 and RM5 in this scenario because I don’t know when this little glitch in my database happened – before RM5 or after RM5.
I decided to fix my database with the following and equally trivial query.
DELETEFROM PlaceTable
WHERE PlaceType =2AND
MasterID =0
But the DELETE query will not run. It gets the infamous error message: SQLite Error 1 – no such collation sequence: RMNOCASE. I don’t understand why there is an RMNOCASE error when both of the data elements I’m testing are numeric.
[inline comment: “why there is an RMNOCASE error when both of the data elements I’m testing are numeric” ve3meo Jan 30, 2012
Because the query tries to delete a record with a field (PlaceTable.Name) that is so collated and that field is used in an index (idxPlaceName) for that table. Hence the index must be updated and cannot be. If you use SQLiteSpy with the fake RMNOCASE extension, you will succeed in deleting these records. However, you should follow up in RM5 with the Database Integrity Check and, if errors reported in an index, then the Reindex tool.
Tom
]
Jerry
Added by Jerry Bryan 3/6/2012
I have concluded that my original description of orphaned Place Details was just a symptom of a larger problem. Namely, somewhere in the process of using the RM 5.0.2.1 feature to split a Place into Place + Place Details and merging any resultant duplicate places, there appears to be a bug whereby one of the duplicate places being merged is deleted without the all the pointers in the EventsTable for that place being adjusted to point to the entry in the PlaceTable that is being kept. The following query will identify all such orphaned place pointers in the Events Table.
/*
This query identifies all events in the EventTable which contain a PlaceID value that does
not appear as a PlaceID value in the PlaceTable. This is an "impossible" situation which
should never occur. However, due to a possible bug in RM 5.0.2.1 or other unknown cause,
this "impossible" situation has occurred one time in my database.
This "impossible" situation occurred after numerous repetitions of splitting a Place
into Place + Place Details and subseqently merging the resultant duplicate Place values.
If the database against which this query is run does not have the problem, then the query
will return no results. So "no results" is the sign of success.
*/SELECT L.EventID, L.EventType, L.OwnerType, L.OwnerID, L.FamilyID, L.PlaceID, P.PlaceID
FROM(SELECT EventID, EventType, OwnerType, OwnerID, FamilyID, PlaceID
FROM EventTable
WHERE PlaceID !=0/* Eliminate events without places in the sub-query */ORDERBY PlaceID, EventID
)AS L
LEFTJOIN
PlaceTable AS P ON L.PlaceID = P.PlaceID
WHERE P.PlaceID ISNULL; /* Events with a place, but the place is not in the PlaceTable */
Discussions & comments from Wikispaces site
Geraniums
No names in “Person” column
Geraniums
23 February 2012 09:17:16
I have about 30 entries where there is no name in the “Person” column. Are these “headless”? How do I fix those?
Other questions:
Once I have finished running the SQLite report, how do I save the results as a text or table, so I can work on it later?
Should the RM program be closed when running SQLite?
in Firefox 10.0.2, the text has black diamonds with question marks. It worked OK in Chrome. Is there a setting in Firefox that needs to be made, or it doesn’t work with FF?
Thanks
Inline comments
ve3meo
Comment: RMGC_Properties – Query flags all unu…
ve3meo
31 January 2012 03:40:05
RMGC_Properties – Query flags all unused Place Details, including those with no master Place, in the row “-Unused Place Details”. However, it does not report a Place Detail used in a fact but lacking a master Place as that may be a legitimate use. For example, the Occupation fact – we might know that he worked at General Motors but not in which municipality. I suggest you run this query as you might discover some other surprises. It needs work to update the Media reporting to RM5.
ve3meo
Comment: Because the query tries to delete a r…
ve3meo
31 January 2012 03:08:40
Because the query tries to delete a record with a field (PlaceTable.Name) that is so collated and that field is used in an index (idxPlaceName) for that table. Hence the index must be updated and cannot be. If you use SQLiteSpy with the fake RMNOCASE extension, you will succeed in deleting these records. However, you should follow up in RM5 with the Database Integrity Check and, if errors reported in an index, then the Reindex tool.
List Persons with specified Surnames.
— Example of creating a SQL View or Virtual Table and the explicit use of COLLATE NOCASE to override the RMNOCASE collation defined for certain fields and embedded in the RootsMagic application.
PlacesDetails
Lists Places having Place Details
UnusedPlaces
List of unused Places
The queries above are included in the one file. Some SQLite managers can import a query file and some can also export a query file (e.g. SQLiteman does both). Others may require you to open the file with a text editor and copy/paste the query into the SQLite manager’s query editor. With SQLiteman, you place the cursor anywhere in a query line and that is the one executed; SQLiteSpy requires you to highlight the selected command and execute using Ctrl+F9 rather than F9 which would run the whole listing. Each query must end with a semi-colon to demark it from the others.
Optionally, the queries can be expanded to include the CREATE VIEW command by deleting the semicolon at the end of its line. When successfully executed, the query is embedded in the database as a virtual table which remains with the database file until it is dropped (deleted). Some SQLite managers allow you to save a query as a view from the user interface, putting a GUI in front an internal CREATE VIEW.
romermb
01 March 2010 20:11:57
I actually intentionally used the same terminology used in RM4 in the Edit shared event screen — This person is not in my file.
Sharee (vs. Sharer) was used to try to differentiate the person sharing in the fact (vs. the one sharing the fact). However, I just looked and realized that it’s not an actual word! I was unable to find it in the dictionary.
Anyway, I grant that the wording could be made better, so will look to improve upon it here shortly.
Thanks.