Rebuttal by Jeff La Marca #sourcetemplates #sources

One of the three source templates compared in the study Source Templates, A Comparative Example.pdf was Jeff La Marca’s Simplified Citations – Census. As it did not fare well in the tests, he has objected strenuously and frequently. To eliminate his need to do so every time I post something that refers to the study, I am including here links to his critiques on his website and in the RootsMagic Forums and invite you, dear reader, to review them and judge for yourself. On reviewing his arguments, I think I have identified why he had such a reaction – see Comment below.

Simple Citations: Making Life Easier for Family Historians Jeff La Marca’s website devoted to his source templates.
Commentary on MyFreeForm “Study” Jeff’s defence of Simple Citations and attack on the methodology of the study.
Problems with MyFreeForm Template Jeff’s attack on the !MyFreeForm3 template.
Forum Discussions:
A Trio of Source Templates (compared)
Adventures in Extreme Splitting
Places / locations on source templates
Whither the Gedcom?

Comment by Tom Holden

I wonder if this entire furor over my study is “Much Ado About Nothing” stemming from Jeff’s missing its basic point and my failing to express it clearly enough. What I advocated in the study and in forum discussions is to use the built-in source templates, Jeff’s if you want, citations from FamilySearch, Ancestry.com, the British Library, on-line generators such as Citation Machine et al to draft a citation that you parse into and save via the Free-Form template, if you want to avoid certain problems, or optionally, !MyFreeForm3 to avoid the same problems and gain an enhancement. I have also advocated for improvement in the RootsMagic application that would mitigate some of these problems and expedite the process of documenting and citing sources.

The point is that the storing of citations under most RM source templates, including Jeff’s custom ones, causes problems for users who may disagree with a template’s split between Master Source and Source Detail (Citation Detail) and produces less than satisfactory, in some cases unacceptable or objectionable, outputs of foot- or end-notes and bibliography. What I concluded from the study was that Free-Form was the storage format most compatible with all the outputs available at the time and that a custom template mimicking Free-Form with some enhancements was about equally compatible while providing the opportunity for Short Footnotes shorter than possible with Free-Form. This !MyFreeForm3 template also allowed the user to set the punctuation between the Master Source part of the footnote and the Source Detail part – that enhancement was motivated in part by Jeff’s own use of “ || ” as the separator in his Simple Citations.

My recommendation was to not use Jeff’s Simple Citations source templates as a storage format, likewise for most of RootsMagic’s built-in source templates. It was not that his source templates should not be used for drafting footnotes and bibliography for parsing into Free-Form, although I pointed out where I thought changes were needed based on the sample source I used (in all three source template sentences). If they suit your style, they readily parse at the “ || ” separator or you can split them elsewhere, according to your position in the “lumping-splitting” spectrum. Unwanted output, such as the Misc.Ref.Num., can be stored in Citation Text Comments. Perhaps that distinction between a source template for storage and source templates for drafting was not made strongly enough.

I think the fundamental cause of confusion is that we tackled two different problems which resulted in what appeared to him as competing and contradictory solutions. From my perspective, they are complementary. Jeff’s solution with Simple Citations is to the problem, and one we share but not addressed by my study, of inputting sources to RootsMagic, starting with having to choose from a plethora of templates. His approach was to seek a universal template from which a small set of sub-templates could be devised to meet the majority of types of sources. This was a commendable effort and one in which I expressed great interest.

The problem my study tackled was that of the outputs. It was disappointing to me that Jeff’s Census template had as many problems as it did (mostly correctable with some change in design) but not surprising that it shared output problems common to most of the built-in source templates, inherent in the design of the RM template system. It became clear that there were serious problems (for me and for others) which could only be resolved by not storing the sources under most of the templates but under Free-Form OR by improvements in the software. I follow the basic principle that inputs and procedures are best designed with reference to the required outputs, i.e., work from the outputs backwards to determine how best to design and use a system to get the results needed.

RootsMagic 5 had as outputs for citations, at the time of the study, three principal output types using citations: printable reports, web pages/sites, and GEDCOM. By 6.2, it has added a new website design and source transfer to FamilySearch Family Tree. Citations delivered through these five different output channels are not altogether consistent (with one newly realised exception) for those stored under the built-in Source Templates except for Free Form and about 17 others of the 413 included. As GEDCOM export to 3rd party software and websites is important to me and to many others, my study was aimed at comparing all the outputs for sources available at the time given the same source citation, one which is generated by an external system (Ancestry.com) and stands up as fulfilling all the requirements of evidence-based reporting as espoused by recognised and respected authorities. The test was to see how closely the outputs of the three source templates could come, via all three channels, to delivering the content of the original citation, completely, accurately, unambiguously, grammatically and acceptably punctuated.

The two new citation output channels and possible bug fixes or other changes since RM 5 may suggest an extension of the study is required but it appears that the five outputs fall into two main groups:

  1. Those that output the Footnote sentence as seen in the Citation Manager (seemingly all but GEDCOM – to be confirmed).
  2. Those that output a hybrid of a part of the Footnote sentence plus a series of field values (to GEDCOM TITL plus PAGE tags, respectively).

Thus the study’s observations may also apply to the new channels if it can be seen that their footnotes belong in one or the other group and not in some third one.

Within the first group, only printable reports deliver also the Short Footnote sentence for citations subsequent to the first of the same source. The old website generator, now in RM6 as “Create HTML files” joins printable reports in having the option to print the Bibliography sentence describing the Master Source for 1 to many citations. Jeff dismisses the latter in his template designs as needing to be no different from the Footnote sentence which is inconsistent with the purpose of a Bibliography – a list of each unique source, regardless of the number of times it has been cited, i.e., all the Master Sources cited in the report, not all the citations.

For those who wish to come close to a finished product with printable reports and HTML pages from RM, consideration should be given also to the quality of the Short Footnotes and Bibliography emanating from a chosen template, given its mapping of source data to its input fields as suggested by the template hints. The study examined all these source outputs and found that Simple Citations – Census needed improvement. Of course, a user is free to not include a Bibliography and Short Footnotes should be suppressed if the Endnote output is selected with the option “Reuse endnote numbers where possible”, thus obviating the need to remedy those sentence templates.

Storing the resulting sentences from any template in free-form affords the opportunity to fix errors without modifying the template, which might have adverse effect on outputs from other sources sharing the template. One is not locked into the straitjacket of a given source template.

Improvements to RootsMagic

The following, in no particular order, are enhancement requests I have made in the past that should result in better quality GEDCOM export and import, promote the use of the built-in source templates, expedite the creation of new sources and citations, achieve greater consistency among citations of the same type of source:

  • Sentence templates within each Source Template for export to GEDCOM tags AUTH, TITL, PUBL, PAGE. This will eliminate the current corruption of citations from many source templates, exploit the standard fully by using the AUTH and PUBL tags where appropriate. Free-Form would continue to export solely to TITL and PAGE.
  • Import GEDCOM sources having the AUTH and/or PUBL tags via a GEDCOM compatible Source Template instead of Free-Form.
  • Source Conversion Utility, 1st priority conversion to Free-Form from all other Source Templates. 2nd priority is conversion between any pair of different templates, including Free-Form.
  • Construct a Free-Form source using the input screen defined by any Source Templates; implies each Source Template has sentence templates for outputs to Free-Form fields: Footnote, Short Footnote, Page, Bibliography. The Source Conversion Utility could rely on these sentence templates. The PAGE export sentence and the Free-Form Page sentence can be the same by default. A register of what template was used for inputting to a Free-Form source would be useful for later recall. This enhancement promotes the use of the built-in templates for style and consistency while editing the Free-Form loosens the straitjacket.
  • Browse sources that use a Source Template from the Source Template manager and copy one to a new source; browse citations that use a selected source and copy to a new source/citation
  • Browse citations of a source from the Source Manager and copy to a new citation of the same source or to a new citation of a new source.
    .

Copy RIN to REFN #update #insert #refno #rin

Some RootsMagic users would like to have a utility to add a Reference Number (REFN) fact to persons that would contain the current Record Number (RIN). The intent is that this REFN would persist through GEDCOM exports and imports, drag’n’drop transfers, and possibly merges, thus providing a reference to the record’s history. I have used this idea to maintain a reference to a family tree published by a cousin from an early version of PAF, to facilitate finding people in his book. There could be many reasons for snapshotting the current RIN. This SQLIte query and attendant procedure makes it easy to do so for any number of persons in a RootsMagic database.

Use RootsMagic:

  1. Backup your database.
  2. Add a REFN fact to any person in your database. You can fill its Description field with garbage or leave blank as you will delete it later. Do NOT add any more facts to anyone until you finish this procedure.
  3. Define a Named Group of persons to whom you want to add REFN facts containing their RINs.
  4. Close RootsMagic (not required but safety first!).

Then use a SQLite manager such as SQLiteSpy:

  1. Open your database
  2. Copy the SQLite query below into the SQL Editor
  3. Open the EventTable and get the EventID from the last row (its EventType should be 35 which is the REFN type).
  4. Substitute the value of EventID from step 2 into the SQLite query in the Editor in place of ‘??EventID??’
  5. Open the LableTable and get the LabelID LabelValue of the row whose LabelName corresponds to the name of your target Group.
  6. Substitute the value of LabelID LabelValue  from step 5 into the SQLite query in the Editor in place of ‘??LabelID??’ ‘??LabelValue??’.
  7. Execute the query.
  8. Assuming no error message, close your database (not required but safety first).

When you next open your database with RootsMagic, you should see the newly added REFN facts in every member of your Named Group. Return to the person you initially added the dummy REFN and delete it.

Here’s the query: rev 2020-05-16 LabelValue instead of LabelID

INSERT OR ROLLBACK INTO EventTable 
        (EventType, OwnerType, OwnerID, FamilyID, PlaceID, SiteID, DATE, SortDate,
         IsPrimary, IsPrivate, Proof, STATUS, EditDate, Sentence, Details, Note)
  SELECT EventType, OwnerType, N.OwnerID, FamilyID, PlaceID, SiteID, DATE, SortDate,
         IsPrimary, IsPrivate, Proof, STATUS, EditDate, Sentence, 'RIN '||N.OwnerID, Note
   FROM (SELECT P.PersonID AS OwnerID FROM PersonTable P, GroupTable 
         WHERE OwnerID >=StartID AND OwnerID <= EndID 
          AND GroupID=??LabelValue??) N,
         EventTable E 
          WHERE EventID=??EventID?? AND EventType=35;

It’s a variant of the Copy Fact to Group query. The differences are few but one significant change was to get the OwnerID from the PersonTable, not the NameTable, as the latter resulted in the addition of multiple facts to the same person if that person had multiple names.

As written, the Description field of the REFN fact will contain ‘RIN n’, where n is the PersonID number. You can change the query to put out some other string in combination with the PersonID by editing the part

'RIN '||N.OwnerID

If you want leading zeroes or blanks so that the REFN is right-justified, the following will work (increase the number of blanks or zeroes if any RINs>9999):

'RIN'||SUBSTR('   ',LENGTH(N.OwnerID))||N.OwnerID -- leading blanks
'RIN'||SUBSTR('000',LENGTH(N.OwnerID))||N.OwnerID -- leading zeroes

All of the added REFN facts will have every other parameter identical to that of the dummy REFN fact, including the same EditDate, hence it is preferable to use a dummy created on the same day that you run the procedure.
If you want the REFN to appear first in the Edit Person screen, then set the SortDate of the dummy REFN to 1 before running the procedure.

Discussions & comments from Wikispaces site


DaiyuHurst

Forcing REFN to be first fact

DaiyuHurst
17 September 2018 18:54:37

I like my REFNs up top. Before even birth. An easy way to do this is to use this slightly altered SELECT statement.
Leaving out the FROM clause for brevity:

SELECT EventType, OwnerType, N.OwnerID, FamilyID, PlaceID, SiteID, DATE, ‘1’,
IsPrimary, IsPrivate, Proof, STATUS, EditDate, Sentence, ‘RIN ‘||N.OwnerID, Note

The curious thing about doing this is, when you examine the individual records in RM, the Sort Date field will no longer be populated, but the effect of the procedure was good, as the REFN fact is the very first fact in each record.

I hope this is useful to someone.


DaiyuHurst

DaiyuHurst
17 September 2018 18:58:30

Oddly, I did not see the last paragraph describing this.

RM Infrastructure to support FSFT

This is just curiosity more than anything, but does anybody here know how the infrastructure in RM works to support FSFT? I can’t find any tables that support FSFT, for example, but I’m probably just missing them. For example, how does RM know who in your RM database has been matched against somebody in FSFT and who has not? Is the required data maybe stored on your account at FSFT itself rather than in your RM database?

Thanks,
Jerry


 

LinkTable

The LinkTable appears to be key to the linkage between RootsMagic and FamilySearch Family Tree. There is one record for each person matched.

DDL

CREATE TABLE LinkTable (LinkID INTEGER PRIMARY KEY, extSystem INTEGER, LinkType INTEGER, rmID INTEGER, extID TEXT, Modified INTEGER, extVersion TEXT, extDate FLOAT, STATUS INTEGER, Note BLOB );
 
CREATE INDEX idxLinkExtId ON LinkTable (extID);

Interpretation

This is based on a very limited test with a small set of persons.

Field NameTypeKeyTypical ValuesNotes
LinkIDIPRIMARY1,2,3,…TBA, not obviously linked to any other table despite sharing name with AddressLinkTable
extSystemI11 probably indicates FamilySearch Family Tree; other values may be available for other external systems.
LinkTypeI00 probably indicates a person
rmIDI1,2,3…(probably, If LinkType = 0, Then) rmID = PersonID or RIN in RM
extIDTText code(probably, If extSystem = 1 AND maybe LinkType=0, Then) extID = FSFT ID, e.g. “9WMY-1KJ”
ModifiedI0,1Appears to be 0=False, 1=True or the complement but unclear what triggers it
extVersionThexadecimal string len=40Changes with changes to the data shared with the FSFT person; thus likely a key component to the comparison and detection of differences over time.
extDateF0unused?
StatusI0unused?
NoteBnullunused?

Query for Sources Without Media #sources #media

I haven’t posted here in rather a long time. Here is a little query I wrote to identify Sources without media. By “Sources”, I mean the same thing that RM calls Master Sources, but I think that they should just be called Sources along with their associated Source Details in common with having Places and Place Details. We do not need to speak of Master Places.

This query is a part of my project to move all sourcing information into the Source area of RM rather than storing some of the sourcing information in the Source Details area of RM. As described on the RM Forums in the thread “Adventures in Extreme Splitting”, I think the tools for managing Source Details are completely inadequate, so I just decided to quit using them. The only way to quit using them is to move all sourcing information into the Source area of RM. And as a part of this project, I’m trying to have at least one media file associated with every Source. This query therefore identifies Sources without media.

I doubt that this query will be of much value to anybody but me, but I think it would be pretty easy to adapt it into being a “Source Details without media” query. Also, it suggests some ways to display information about media files that are totally unavailable within RM itself.

Jerry

sources_without_media.sql

Added 06/18/2013

While I was at it, I decided to do a query to display the Master Source name along with the associated footnote sentence. I couldn’t figure out how to do it with SQLiteSpy so I did it with Access. I need to study further one of Tom’s pages on parsing XML. It might be much easier with his technique than with what I was trying to do. Also, it only worked for me because I was using the built-in Free Form source template, so all I had to do was to look for the <Footnote> tag in the XML.

The reason I had to use Access is that the INSTR function is not yet supported in SQLiteSpy, which is my SQLite manager of choice. Tom documented some alternative mangers that do support INSTR. But when I tried to download them, I got into a messy situation where the download sites were trying to download all manner of “annoy-ware” along with the SQLite manager. I was very uncomfortable with what was going on, so I abandoned the downloads and switched to Access instead for this particular query. In case this might help anybody despite that fact that it’s Access, here it is.

SELECT Left(S.Footnote,S.Footnote_Len) AS Footnote, S.Name
FROM (SELECT SS.Name, SS.Footnote, InStr(1,SS.Footnote,"</Value></Field><Field>")-1 AS Footnote_Len
      FROM (SELECT SSS.Name, Mid(SSS.Fields,SSS.Footnote_Begin_Less22+22) AS Footnote
            FROM (SELECT SSSS.Name, SSSS.Fields, InStr(1,SSSS.Fields,"Footnote") AS Footnote_Begin_Less22
                  FROM (SELECT Left(SSSSS.Name,Len(SSSSS.Name)) AS Name, StrConv(SSSSS.Fields,64) AS Fields
                        FROM SourceTable AS SSSSS) AS SSSS) AS SSS) AS SS) AS S
ORDER BY footnote

The StrConv function is sort of the Access version of CAST. The argument 64 is not a length. Rather, it’s a flag of what type of conversion is required. InStr is a string searching function which I believe is identical to INSTR in SQLite. The fact that InStr would work in Access is why I used Access.

Here is a bit of what the report looks like. I like the report because it makes it very easy to eyeball various footnote sentences for consistency. This is a genealogical comment rather than an SQLite one, but I’m not very happy with some aspects of the footnote sentences. For example, I often don’t have the marriage book number or page number – only the license number. But that’s because Knox County does not give public access to the marriage books and the information I get from them usually only has the license number. But the license number plus the year actually is sufficient to uniquely identify the record.

Just as a reminder: because of my Extreme Source Splitting strategy, 100% of the footnote sentence may be found in the Master Source area of RM, which is the whole point of this exercise. No matter how many times the Master Source is cited, I can make any needed edits or corrections to the citation just one time and the change takes place for all instances of the citation.

And as a further reminder (and as documented in the sources_without_media.sql query above), every one of these Master Sources and footnote sentences will be supported by an appropriate collection of media files – and I only have to process each media file one time and it immediately is linked to every citation where the respective Master Source is used, again which is the whole point of this exercise.

Jerry

   Master Source Name                                    Footnote Sentence

6-18-2013 5-44-39 PM.png



Added 6/19/2013

Armed with the new version of SQLiteSpy, I rewrote the footnote query directly in SQLite rather than it having to be in Access. The query is still dependent upon the footnote having been generated by the built-in FreeForm template. Moving forward, I would like to be able to switch over to real Source Templates that place all the data into the Master Source. But if I do, I would still very much like to be able to run something equivalent to this query to display my footnote
sentences in the context of other footnote sentences.

I’m cognizant of the fact this query could have been written without as many levels of nested subqueries, but the subqueries made the query extremely easy to write. Several manipulations have to be performed on the XML to coerce it into being the footnote sentence, and each level of subquery performs one of the needed manipulations.

Jerry

SELECT S.Name AS Name, SUBSTR(S.Footnote,1,S.Footnote_Len) AS Footnote
FROM (SELECT SS.Name, SS.Footnote, INSTR(SS.Footnote,'</Value></Field><Field>')-1 AS Footnote_Len
      FROM (SELECT SSS.Name, SUBSTR(SSS.Fields,SSS.Footnote_Begin) AS Footnote
            FROM (SELECT SSSS.Name, SSSS.Fields, INSTR(SSSS.Fields,'Footnote')+22 AS Footnote_Begin
                  FROM (SELECT SSSSS.Name AS NAME, CAST(SSSSS.Fields AS TEXT) AS Fields
                        FROM SourceTable AS SSSSS) AS SSSS) AS SSS) AS SS) AS S
ORDER BY Footnote

Discussions & comments from Wikispaces site


ve3meo

Inline comment: “INSTR function is not yet supported in SQLiteSpy‍,”

ve3meo
04 September 2018 01:36:57

ve3meo Jun 18, 2013

The current version of SQLiteSpy does support INSTR.
thejerrybryan Jun 18, 2013

Thanks for the update. The newest version appears to be 1.9.3. However, I seem to have created a problem for myself. Namely, there is something wrong with RMNOCASE and SourceTable. Something so simple as “SELECT SourceID from SourceTable” throws the RMNOCASE error, and SourceID is a numeric field. I can’t even double click on the SourceTable just to view the whole thing. It appears to be the case that SourceTable is the only table with this problem.

Jerry
thejerrybryan Jun 18, 2013

SELECT * FROM SourceTable does work, however.
ve3meo Jun 18, 2013

This does not make sense – something is royally screwed up. Even a SELECT of a field defined with the RMNOCASE collation should not throw the error unless it is sorted. And under Options > Options > Extensions, do you have RMNOCASE_fake-SQLiteSpy.dll? If so, then there should be no such errors on any RMNOCASE defined field. In SQLiteSpy, run REINDEX and see if that clears the problem. When you return to RootsMagic, use its Rebuild Indexes tool before resuming normal operations.

Tom
thejerrybryan Jun 18, 2013

I hadn’t applied the fake RMNOCASE since I upgraded to 1.9.3. I have now done so, and the problem is solved. But as you say, there should be no error unless something is sorted. It’s almost like 1.9.3 is sorting something behind the scenes that we don’t know about. And the error is thrown even if I explicitly override the collation with NOCASE.

Also, I was wrong about it being just SourceTable. The error also occurs in AddressTable, MediaLinkTable, ResearchTable, and SourceTemplateTable. These are tables I never run queries against, so the problem could have been there forever. And I didn’t even try to run against SourceTable after I realized that INSTR wouldn’t work with my current version of SQLiteSpy.

If you have 1.9.3, you might try temporarily taking away the fake RMNOCASE collation to see if you also have the problem. Indeed, if you widen the window pane that contains the list of tables on the left side of the screen, the tables in question all have an error message beside them. You don’t even have to run a query or double click one of the tables to see the problem.

After removing the fake RMNOCASE collation, you will have to shut down SQLiteSpy and restart it to see the effect, and vice versa when you put it back.

Jerry
thejerrybryan Jun 18, 2013

On a lark, I restored 1.9.0. It does not have the RMNOCASE problem when the fake RMNOCASE collation is not installed. Which is to say you can access all the tables if you don’t sort. Without the fake RMNOCASE collation, you obviously have to do something to deal with RMNOCASE if you do sort. But the problem I’m describing was definitely introduced sometime between 1.9.0 and 1.9.3.

Jerry
ve3meo Jun 18, 2013

Too late for me now to do the testing you suggest. Between SQLiteSpy 1.9.0 and 1.9.3, SQLite itself has changed and I would suspect the problem or effect of a missing collation lies there. That should also manifest itself in the DOS executable of SQLite.
ve3meo Jun 18, 2013

The behaviour you describe is now inherent in SQLite itself (I see it in the Windows command line shell) and is not the fault of SQLiteSpy. ‘Why’ is a mystery but it may have something to do with query optimisation or auto-indexing. Or maybe it is an unwarranted bug.
thejerrybryan Jun 18, 2013

So I guess the fake RMNOCASE collation is now the only RMNOCASE solution for those tables that have the problem I’m describing. Even explicitly overriding the collation in a query does not take care of the problem. So I’ll probably just go with the fake RMNOCASE from now on and not even try to influence collation explicitly in my queries.

Jerry
ve3meo Jun 18, 2013

And don’t update your odbc connection between Access and SQLite databases. Even though a later version might resolve some issues, maybe it will be unusable. I’m now pretty sure this problem has to do with SQLite’s query optimiser trying to use an Index that is on a field having the RMNOCASE collation. I don’t see any way of turning off the optimiser. Dropping the index might clear that problem but introduce others such as loss of speed and the need to regenerate the index for ongoing use by RootsMagic.

Tom
thejerrybryan Jun 18, 2013

I had wondered what might happen with ODBC and Access. So far, nothing bad has happened to me.

It is the case that Access suffers from the RMNOCASE problem just like SQLiteSpy does. There not being a fake RMNOCASE solution available to Access, the trick that has worked for me 100% of the time is to substring out any RMNOCASE field that I need to sort on, and do the “substring out” thing in a subquery that passes the substring up to the next higher level of subquery. The substring operation I perform makes a “substring” of the whole field without dropping any characters.

There is more information about this issue with RMNOCASE and Access elsewhere in the Wiki. Because of the nature of Access, it’s often the case that your query does not actually need to sort directly on one of the RMNOCASE fields. But you will still want to use a trick to make the field sortable anyway. That’s because of the visual nature of Access where you can click on the column headers of the result of a query and sort by that column even though the column wasn’t sorted in the original query. The ability to sort in this fashion is lost unless you suppress the RMNOCASE problem.

Jerry
ve3meo Jun 18, 2013

I rejoined the sqlite-users list and posted the problem. I have had replies from both D. Richard Hipp, lead developer of SQLite, and Ralf Junker, developer of SQLiteSpy. I have a better understanding of what’s going on, a partial work-around but concluding that any recent SQLite manager must have at least the fake RMNOCASE collation for it to be able to use any of the queries and scripts developed for the RootsMagic4+ databases. Now if only Bruce would reveal the real RMNOCASE (are you reading this, Bruce?). The discussion begins at [sqlite] False Error ‘no such collation sequence’ http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2013-June/046965.html

Tom
ve3meo Jun 18, 2013

The current version of the ODBC driver from http://www.ch-werner.de/sqliteodbc/ wraps the (current) SQLIte 3.7.17 library. Since the command line version sqlite3.exe is built from 3.7.17 and exhibits the same problems as SQLiteSpy 1.9.3, built from 3.7.16.1, I would not be surprised if the current ODBC introduced some sort of problem in your MS Access interface.

Tom

Inline comments


ve3meo

Comment: The current version of SQLiteSpy does…

ve3meo
18 June 2013 23:28:55

The current version of SQLiteSpy does support INSTR.


thejerrybryan

thejerrybryan
19 June 2013 01:22:18

Thanks for the update. The newest version appears to be 1.9.3. However, I seem to have created a problem for myself. Namely, there is something wrong with RMNOCASE and SourceTable. Something so simple as “SELECT SourceID from SourceTable” throws the RMNOCASE error, and SourceID is a numeric field. I can’t even double click on the SourceTable just to view the whole thing. It appears to be the case that SourceTable is the only table with this problem.

Jerry


thejerrybryan

thejerrybryan
19 June 2013 01:25:24

SELECT * FROM SourceTable does work, however.


ve3meo

ve3meo
19 June 2013 02:27:25

This does not make sense – something is royally screwed up. Even a SELECT of a field defined with the RMNOCASE collation should not throw the error unless it is sorted. And under Options > Options > Extensions, do you have RMNOCASE_fake-SQLiteSpy.dll? If so, then there should be no such errors on any RMNOCASE defined field. In SQLiteSpy, run REINDEX and see if that clears the problem. When you return to RootsMagic, use its Rebuild Indexes tool before resuming normal operations.

Tom


thejerrybryan

thejerrybryan
19 June 2013 03:17:48

I hadn’t applied the fake RMNOCASE since I upgraded to 1.9.3. I have now done so, and the problem is solved. But as you say, there should be no error unless something is sorted. It’s almost like 1.9.3 is sorting something behind the scenes that we don’t know about. And the error is thrown even if I explicitly override the collation with NOCASE.

Also, I was wrong about it being just SourceTable. The error also occurs in AddressTable, MediaLinkTable, ResearchTable, and SourceTemplateTable. These are tables I never run queries against, so the problem could have been there forever. And I didn’t even try to run against SourceTable after I realized that INSTR wouldn’t work with my current version of SQLiteSpy.

If you have 1.9.3, you might try temporarily taking away the fake RMNOCASE collation to see if you also have the problem. Indeed, if you widen the window pane that contains the list of tables on the left side of the screen, the tables in question all have an error message beside them. You don’t even have to run a query or double click one of the tables to see the problem.

After removing the fake RMNOCASE collation, you will have to shut down SQLiteSpy and restart it to see the effect, and vice versa when you put it back.

Jerry


thejerrybryan

thejerrybryan
19 June 2013 03:43:58

On a lark, I restored 1.9.0. It does not have the RMNOCASE problem when the fake RMNOCASE collation is not installed. Which is to say you can access all the tables if you don’t sort. Without the fake RMNOCASE collation, you obviously have to do something to deal with RMNOCASE if you do sort. But the problem I’m describing was definitely introduced sometime between 1.9.0 and 1.9.3.

Jerry


ve3meo

ve3meo
19 June 2013 03:56:06

Too late for me now to do the testing you suggest. Between SQLiteSpy 1.9.0 and 1.9.3, SQLite itself has changed and I would suspect the problem or effect of a missing collation lies there. That should also manifest itself in the DOS executable of SQLite.


ve3meo

ve3meo
19 June 2013 14:13:26

The behaviour you describe is now inherent in SQLite itself (I see it in the Windows command line shell) and is not the fault of SQLiteSpy. ‘Why’ is a mystery but it may have something to do with query optimisation or auto-indexing. Or maybe it is an unwarranted bug.


thejerrybryan

thejerrybryan
19 June 2013 18:27:12

So I guess the fake RMNOCASE collation is now the only RMNOCASE solution for those tables that have the problem I’m describing. Even explicitly overriding the collation in a query does not take care of the problem. So I’ll probably just go with the fake RMNOCASE from now on and not even try to influence collation explicitly in my queries.

Jerry


ve3meo

ve3meo
19 June 2013 18:42:24

And don’t update your odbc connection between Access and SQLite databases. Even though a later version might resolve some issues, maybe it will be unusable. I’m now pretty sure this problem has to do with SQLite’s query optimiser trying to use an Index that is on a field having the RMNOCASE collation. I don’t see any way of turning off the optimiser. Dropping the index might clear that problem but introduce others such as loss of speed and the need to regenerate the index for ongoing use by RootsMagic.

Tom


thejerrybryan

thejerrybryan
19 June 2013 19:58:07

I had wondered what might happen with ODBC and Access. So far, nothing bad has happened to me.

It is the case that Access suffers from the RMNOCASE problem just like SQLiteSpy does. There not being a fake RMNOCASE solution available to Access, the trick that has worked for me 100% of the time is to substring out any RMNOCASE field that I need to sort on, and do the “substring out” thing in a subquery that passes the substring up to the next higher level of subquery. The substring operation I perform makes a “substring” of the whole field without dropping any characters.

There is more information about this issue with RMNOCASE and Access elsewhere in the Wiki. Because of the nature of Access, it’s often the case that your query does not actually need to sort directly on one of the RMNOCASE fields. But you will still want to use a trick to make the field sortable anyway. That’s because of the visual nature of Access where you can click on the column headers of the result of a query and sort by that column even though the column wasn’t sorted in the original query. The ability to sort in this fashion is lost unless you suppress the RMNOCASE problem.

Jerry


ve3meo

ve3meo
21 June 2013 03:28:46

I rejoined the sqlite-users list and posted the problem. I have had replies from both D. Richard Hipp, lead developer of SQLite, and Ralf Junker, developer of SQLiteSpy. I have a better understanding of what’s going on, a partial work-around but concluding that any recent SQLite manager must have at least the fake RMNOCASE collation for it to be able to use any of the queries and scripts developed for the RootsMagic4+ databases. Now if only Bruce would reveal the real RMNOCASE (are you reading this, Bruce?). The discussion begins at [sqlite] False Error ‘no such collation sequence’ http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2013-June/046965.html

Tom


ve3meo

ve3meo
21 June 2013 03:36:20

The current version of the ODBC driver from http://www.ch-werner.de/sqliteodbc/ wraps the (current) SQLIte 3.7.17 library. Since the command line version sqlite3.exe is built from 3.7.17 and exhibits the same problems as SQLiteSpy 1.9.3, built from 3.7.16.1, I would not be surprised if the current ODBC introduced some sort of problem in your MS Access interface.

Tom

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.