Addresses – How Used #RM7

As of 5.0.4.2, RootsMagic does not provide a comprehensive report on how each entry in the Address List is used – is it merely a Contact or is it the address of a Person or Family (couple) in the tree database? This query provides a list which helps answer that need.

RM does provide a comprehensive report on how each Repository is used by Sources, To Do tasks and Correspondence. Because Repository addresses are stored in the same table as Contact, Person and Family addresses, this query includes summary information on the usage of all addresses.

The query results are laid out with the basic address information in the left columns and the usage report in the two right-hand columns, User type and Used by. The basic address data includes Name, Street, Place, Primary. Place is the reverse concatenation of City, State, Country which affords a convenient geopolitical sort when ordered alphabetically. Primary indicates whether the address is Primary (Y) or Secondary (N), applicable only to Repositories.

The query has been tested on SQLiteSpy with the dummy RMNOCASE extension.

Addresses-HowUsed.sql RMtrix_tiny_check.png

AddressHowUsed-RM7.sql rev 2021-07-03 for cleaner results for Contacts. Incompatible with RM8

WebTags – Consolidate #webtags #delete #citations

Rev 2023-02-23 added versions for #RM8

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.

RM8 Version

Pre-RM8 Version

WebTags-Consolidate.sql RMtrix_tiny_check.pngWebTags-DeleteDuplicates.sql RMtrix_tiny_check.png
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)
*/
 
INSERT OR REPLACE INTO URLTable
--- Citation WebTags ----
-- Person for citations of Persons
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Cit.OwnerID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN
    CitationTable AS Cit
  ON URL.OwnerID = Cit.CitationID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 0
UNION
-- Fathers for citations of families
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Fam.FatherID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN FamilyTable AS Fam
    ON Cit.OwnerID = Fam.FamilyID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 1
 
UNION
-- Mothers for citations of families
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Fam.MotherID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN FamilyTable AS Fam
    ON Cit.OwnerID = Fam.FamilyID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 1
 
UNION
-- Person for citations of individual events
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Evt.OwnerID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN EventTable Evt
    ON Cit.OwnerID = Evt.EventID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 2 -- Event citation
    AND Evt.OwnerType = 0 -- Person
 
UNION
-- Husband for citations of Family events
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Fam.FatherID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN EventTable Evt
    ON Cit.OwnerID = Evt.EventID
  INNER JOIN FamilyTable Fam
    ON Evt.OwnerID = Fam.FamilyID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 2 -- Event citation
    AND Evt.OwnerType = 1 -- Family
 
UNION
-- Wife for citations of Family events
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Fam.MotherID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN EventTable Evt
    ON Cit.OwnerID = Evt.EventID
  INNER JOIN FamilyTable Fam
    ON Evt.OwnerID = Fam.FamilyID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 2 -- Event citation
    AND Evt.OwnerType = 1 -- Family
 
UNION
-- Person for citations of Alternate Names
SELECT
  NULL AS LinkID,
  0 AS OwnerType,
  Nam.OwnerID AS OwnerID,
  0 AS LinkType,
  URL.Name AS Name,
  URL.URL AS URL,
  URL.Note AS Note
  FROM URLTable URL
  INNER JOIN
    CitationTable AS Cit
    ON URL.OwnerID = Cit.CitationID
  INNER JOIN NameTable Nam
    ON Cit.OwnerID = Nam.NameID
  WHERE URL.OwnerType = 4 -- Citation webtag
    AND Cit.OwnerType = 7 -- Alt Name citation
--- End of Citation WebTags ----
;

WebTags – from Ancestry.com and FTM #ancestrycom #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:

  1. The comment must begin with “http://” else it will be skipped.
  2. 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 RMtrix_tiny_check.png

-- WebTags-MakeFromAncestryComments.sql
/*
2012-12-10 Tom Holden ve3meo
 
Inspects for Citation Comments beginning with "http://" 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 "http://"
INSERT OR REPLACE INTO URLTable
SELECT
  (SELECT LinkID FROM URLTable WHERE OwnerType=4 AND OwnerID=Cit.CitationID) AS LinkID,
  4 AS OwnerType,
  Cit.CitationID AS OwnerID,
  0 AS 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
  INNER JOIN SourceTable AS Src
  USING (SourceID)
 
WHERE Cit.Comments LIKE 'http://%'
;

RM4 To Do List #todolist #tasks #date

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.

Download: To-Do.sql RMtrix_tiny_check.png

DBManager_To-Do.png
Screen shot from DBTools DBManager

A Query for a To Do List in a Grid Format #todolist #msaccess #rmnocase

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.
RMtrix_tiny_check.png

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=0 AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6
 
         )  AS L
 
 
           LEFT JOIN
 
 
         (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
                      INNER JOIN
                  FactTypeTable AS F ON E.EventType=F.FactTypeID
 
                  WHERE F.FactTypeID=35
                  GROUP BY E.OwnerID
 
         )  AS R ON R.RecNo = L.RecNo
 
ORDER BY 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=0 AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6
 
         )  AS L
 
 
           LEFT JOIN
 
 
         (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
                      INNER JOIN
                  FactTypeTable AS F ON E.EventType=F.FactTypeID
 
                  WHERE F.FactTypeID=35
                  GROUP BY E.OwnerID
 
         )  AS R ON R.RecNo = L.RecNo
 
ORDER BY Surname, Given

Here is some further discussion of the scripts.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. I hard coded the Reference Number fact as fact #35 for the same reason I hard coded my group as group #6.
  9. 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

todoreport.jpg

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=0 AND N.OwnerID>=G.StartID AND N.OwnerID<=G.EndID AND G.GroupID=6
 
        )  AS L
 
                        LEFT JOIN
        (
         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=35
           GROUP BY
                     E.OwnerID
 
        )  AS R ON L.RecNo = R.RecNo
 
  ORDER BY L.Surname, L.Given

Here’s a screen shot of the query when it is run against my live RM4 database.

Clipboard01.jpg

Multiple Spouses query #spouse #multiples

Update 2021-03-11: compatible with RM4 to #RM8

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.

Multi-spouses.sql  RMtrix_tiny_check.png

Multi-spouses.png
Screenshot from SQLiteSpy showing the query and some of the results. Surnames blurred for privacy.

People Who Share A Fact with a Principal, But Who Are Not in a Tree in The File List – Query #sharedevent #person

Description

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.
RMtrix_tiny_check.png – 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 Facts
SELECT   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 AS ROLE,
         FactTypeTable.Name COLLATE NOCASE AS Fact,
         NULL AS 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,
         NULL AS RIN2,
         NULL AS Surname2,
         NULL AS Suffix2,
         NULL AS Prefix2,
         NULL AS Given2
FROM     WitnessTable
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN NameTable ON
         EventTable.OwnerID = NameTable.OwnerID
WHERE    WitnessTable.PersonID = 0 AND EventTable.OwnerType = 0 AND
         NameTable.IsPrimary = 1
 
UNION ALL
 
-- Family Facts
SELECT   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 AS ROLE,
         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
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN FamilyTable ON
         EventTable.OwnerID = FamilyTable.FamilyID
         LEFT OUTER JOIN NameTable AS NameTable1 ON
         FamilyTable.FatherID = NameTable1.OwnerID
         LEFT OUTER JOIN NameTable AS NameTable2 ON
         FamilyTable.MotherID = NameTable2.OwnerID
WHERE    WitnessTable.PersonID = 0 AND EventTable.OwnerType = 1 AND
         NameTable1.IsPrimary = 1 AND NameTable2.IsPrimary = 1
 
ORDER BY 1, 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.

Thanks.

People Who Share a Fact with a Principal List – Query #sharedevent #person

Description

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:

RMtrix_tiny_check.png and compatible with RM4- #RM7 and #RM8

-- People Who Share A Fact with a Principal List
-- created by romermb on 10 Mar 2010
 
-- Individual Facts, Person Sharing Fact in Tree in File
SELECT   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 AS ROLE,
         FactTypeTable.Name COLLATE NOCASE AS Fact,
         NULL 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,
         NULL AS RIN2,
         NULL AS Surname2,
         NULL AS Suffix2,
         NULL AS Prefix2,
         NULL AS Given2
FROM     WitnessTable
         LEFT OUTER JOIN NameTable ON
         WitnessTable.PersonID = NameTable.OwnerID
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN NameTable AS NameTable1 ON
         EventTable.OwnerID = NameTable1.OwnerID
WHERE    WitnessTable.PersonID <> 0 AND EventTable.OwnerType = 0 AND
         NameTable.IsPrimary = 1 AND NameTable1.IsPrimary = 1
 
UNION ALL
 
-- Family Facts, Person Sharing Fact in Tree in File
SELECT   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 AS ROLE,
         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
         LEFT OUTER JOIN NameTable ON
         WitnessTable.PersonID = NameTable.OwnerID
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN FamilyTable ON
         EventTable.OwnerID = FamilyTable.FamilyID
         LEFT OUTER JOIN NameTable AS NameTable1 ON
         FamilyTable.FatherID = NameTable1.OwnerID
         LEFT OUTER JOIN NameTable AS NameTable2 ON
         FamilyTable.MotherID = NameTable2.OwnerID
WHERE    WitnessTable.PersonID <> 0 AND EventTable.OwnerType = 1 AND
         NameTable.IsPrimary = 1 AND NameTable1.IsPrimary = 1 AND NameTable2.IsPrimary = 1
 
UNION ALL
 
-- Individual Facts, Person Sharing Fact Not in Tree in File
SELECT   NULL AS 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 AS ROLE,
         FactTypeTable.Name COLLATE NOCASE AS Fact,
         NULL AS 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,
         NULL AS RIN2,
         NULL AS Surname2,
         NULL AS Suffix2,
         NULL AS Prefix2,
         NULL AS Given2
FROM     WitnessTable
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN NameTable ON
         EventTable.OwnerID = NameTable.OwnerID
WHERE    WitnessTable.PersonID = 0 AND EventTable.OwnerType = 0 AND
         NameTable.IsPrimary = 1
 
UNION ALL
 
-- Family Facts, Person Sharing Fact Not in Tree in File
SELECT   NULL AS 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 AS ROLE,
         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
         LEFT OUTER JOIN RoleTable ON
         WitnessTable.ROLE = RoleTable.RoleID
         LEFT OUTER JOIN EventTable ON
         WitnessTable.EventID = EventTable.EventID
         LEFT OUTER JOIN FactTypeTable ON
         EventTable.EventType = FactTypeTable.FactTypeID
         LEFT OUTER JOIN FamilyTable ON
         EventTable.OwnerID = FamilyTable.FamilyID
         LEFT OUTER JOIN NameTable AS NameTable1 ON
         FamilyTable.FatherID = NameTable1.OwnerID
         LEFT OUTER JOIN NameTable AS NameTable2 ON
         FamilyTable.MotherID = NameTable2.OwnerID
WHERE    WitnessTable.PersonID = 0 AND EventTable.OwnerType = 1 AND
         NameTable1.IsPrimary = 1 AND NameTable2.IsPrimary = 1
 
ORDER BY 2, 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
jweaber@gmail.com


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!

Paragraphing #update #paragraphing #reports

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 RMtrix_tiny_check.png 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 RMtrix_tiny_check.png 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.

Place Details without a Place #placedetails #phantom

Orphaned Place Details

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.

OrphanedPlaceDetailsScreenshot.PNG
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

  1. What is an Orphaned Place Detail? It’s a Place Detail for which there is no parent Place in the PlaceTable.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Downloads

OrphanedPlaceDetails.sqlRMtrix_tiny_check.png

OrphanedPlaceDetails_DeleteUnused.sqlRMtrix_tiny_check.png


Original Post from Jerry Bryan

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 = 2
                 AND
          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:

external image user_none_lg.jpg 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.

DELETE
    FROM PlaceTable
    WHERE PlaceType = 2
                 AND
          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”

external image user_none_lg.jpg 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  */
        ORDER BY PlaceID, EventID
       ) AS L
 
             LEFT JOIN
 
        PlaceTable AS P ON L.PlaceID = P.PlaceID
 
    WHERE P.PlaceID IS NULL;     /* 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?

Thanks


Geraniums

Geraniums
23 February 2012 09:19:43

One other question, is when I went here:

http://sqlitetoolsforrootsmagic.com/wp-content/uploads/2019/01/OrphanedPlaceDetails.sql

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.

Tom