* Show Project Statistics V1.5/6 Plugin

[johnmorrisoniom]

I have run ver 1.5 twice now, took over 4 hours to complete on my XP machine, but only 45 mins on my W7 machine.

Showed up quite a few errors that I had not seen before.

However the result set produced is Odd.

result set error.JPG (91.59 KiB) Viewed 12077 times

Note that the correct error is picked out, but an incorrect individual is show. This seems to apply to all the ones I have looked at so far.

[tatewise]

I'm a little surprised that the Plugin takes so long, even on your large database, but perhaps the extra Date warning checks are the cause.

From my testing, I would have expected that the Fact Date is warnings to have listed a related Fact in the first column rather than an Individual.
What did you discover were the offending Facts ?

Also note the following quote from the plugins:help:show_project_statistics:result_set_exceptions|> Plugin Help & Advice page:

Take care when checking Exceptions associated with Family Facts such as Marriage or Divorce. After clicking the Fact Item in the Result Set, the Individual Property Box displayed may NOT exhibit the problem, so remember to check the Spouse Property Box too.

Further investigation has revealed some similar misleading Exception Reports that have already been fixed as a side effect of other changes I have in the pipeline.
I will endeavour to update the Plugin in the Plugin Store ASAP, hopefully on Monday.

[johnmorrisoniom]

In the example shown, Elizabeth Locke is not connected to the marriage of William Buckley Wood, but did marry the Williams Brother-in-law 3 years later.
I am not too worried about the length of time on my XP machine. The computer is getting a bit tired now. Will just make sure I run it on the W7 machine.

[tatewise]

I have found the problem - a minor oversight of mine in the Plugin script - SORRY!

V1.6 is now in the Plugin Store with bug fixed and a few other minor improvements.

[LornaCraig]

Mike,
I just tried to upgrade this plugin by running the Check Installed Plugins Against the Store plugin, but the result set showed that the Show Project Statistics plugin is not in the store at all. Has the old version been removed but the new one is still awaiting approval?

[Jane]

When plugins are updated they "disappear" from the Store until Calico approve the code.

[tatewise]

I am sure it was and is in the Plugin Store ! I checked before I posted.

The problem appears to be with Check Installed Plugins Against The Store Plugin.
It is currently saying

COM exception:(.\src\library\tLuaCOM.cpp,394):The server returned an invalid or unrecognized response

Whereas a variant of this Plugin that I use works OK.
It is available via my SkyDrive at Check Installed Plugins Against The Store - MBT
All changes from Jane's original are identified with --! comment marks, and cvtVer() function is replaced by IntVersion() and string.split() functions.

[LornaCraig]

Thanks Mike, it is now. It wasn't half an hour ago!

Edit:
I don't think the problem was the Check Installed Plugins Against The Store Plugin. When it first failed to find Show Project Statistics in the store I browsed the store direct and it definitely wasn't there.
Then half an hour later it was there and when I ran Check Installed Plugins Against The Store it found it.

I assumed that the upgrade was awaiting approval, as Jane said.

[johnmorrisoniom]

Hi Mike.

The latest version is showing up errors ( But not reporting some of them) that I have been unable to track down.

Screen Shot.

Fact Date Screen.JPG (133.35 KiB) Viewed 11954 times

I have tried vaious searches to find the items dated 3 Nov 0008, no luck so far. I already had a query set up for Age@ Christening, which shows maximum age to be 31.

I have also been able to find anyone in my file born age 5?

[tatewise]

Dates
As explained in thread Change Any Fact Tag filters (10861), Date fields within FH must be searched for using full month names, despite often being displayed abbreviated. So 3 Nov 0008 must be searched for using 3 November 0008. Also Date fields within FH are NOT plain text, so any text search will not find them. e.g. FH Edit > Find Record won't, and any Plugins that search text won't.

Plugin Date Search and Return Result Set simply needed 0008 to find such rogue Dates.
My new Plugin in thread Possible enhancement for Search and Replace (6069) finds & replaces such Dates OK.

Finally, in GEDCOM files, such Date fields are stored as DATE 3 NOV 0008 and here a plain text search does work.

Age At
If your Age@Christening is a Fact Query using %FACT.DATE:AGE_AT% qualifier then many Date formats are not supported. A better option is the =AgeAt(FactOwner(%FACT%,1,MALES_FIRST),%FACT.DATE%) function.

The same applies to a Fact Query for Age@Birth and an Age@ greater than 0 indicates there are two Birth Events for the Individual, and so only a Fact Query is likely to find it, because it will be %FACT.BIRT[2]% i.e. 2nd instance of BIRT that an Individual Query usually won't cater for.

BTW:
The Show Project Statistics Plugin does not Report such Dates or Age@ as Exceptions because, although unusual, they are not strictly invalid. However, with hindsight, perhaps Dates earlier than say 1000 might warrant an Exception Report.

[johnmorrisoniom]

Thanks for your help Mike.

The MBT search and replace worked beautifully by limiting it to just dates and search for 0008 replace with 2008 and so on.

I do know how these errors crept in. Although there is error checking when you enter a fact date in FH, there is no error checking on a citation date. I use the citation date with today's date (That was the day that I am citing the source) and it is very easy to type in 22/10/13 as I would normally do in excel ( although in excel only 22/10 would be needed for current year) instead of the needed 22/10/2013.

Maybe another item for the wish list.?

[tatewise]

Having fixed the bug, does this Plugin still take 45 mins to run on your large database?

Have you also sorted out the Age@ problems?

Using the Citation Entry Date that way is an unconventional but often used approach.
The GEDCOM Specification says it should be...

The date that this event data was entered into the original source document.

... rather than the Date you happened to link it into your data.

The next version of the Statistics Plugin will Report Dates earlier than 1000 AD.
Hopefully there won't be too many people creating Roman or similar family trees.

[capnkeith]

Excuse me butting in to this thread, but after reading it, I ran the plugin on my project. It found a few problems most of which I can fix / have fixed.
One little niggle it came up with a perceived error, where I have only a quarter date for a birth but have the exact date of the baptism. The baptism date was within the quarter period but it told me the baptism was wrong as it was before the birth date.
Is that something you are aware of or that can be changed.

[johnmorrisoniom]

Thanks Mike,
I had previously done a query with your help to sort out the age@ problems, but it needed a few teeks to do what I wanted. All sorted now (I hope). The 1.6 version took just over 45mins on my W7 desktop machine. I am happy with this run time as it was about what I was expecting. I only intend to run it about once a month anyway.

Keep up the good work, your plugins are amazing. Sorry I keep finding bugs, but that's why I like Beta testing.

[tatewise]

Keith,
Those Fact Date warnings are simply what you get if you enter the Dates using FH V5.
If you edit the Birth Event Date by simply deleting and retyping its Quarter Date digit then you will get:
Possible Error
Date range extends later than at least one "life" event recorded for this Individual.

Bear in mind that a Quarter Date is just a Date Range in disguise.

The Statistics Plugin is reproducing these same warnings for the benefit of user's data entered prior to FH V5.

I think the Exception Report is actually against the Birth Event Date, not the Baptism Event Date.
Nevertheless, it is saying they are in conflict, which they are.
The Date Range for the Quarter Date does extend later than a "life" event - the Baptism.

Since it is only a warning it can be ignored, but as it comes from FH itself the Plugin cannot change it.

The only alternative course of action is to change the Birth Event Date to a Date Range running between the start of the Quarter and the Baptism Date.

[johnmorrisoniom]

The only alternative course of action is to change the Birth Event Date to a Date Range running between the start of the Quarter and the Baptism Date.

but even that is not strictly accurate, because the actual birth could have taken place before the start of the quarter. The quarter date is the date of the return to GRO.

[tatewise]

You are absolutely correct, so the Baptism could take place before the beginning of the Birth GRO Quarter Date

To be absolutely pedantic, we should be recording a Birth Registration Event with the Quarter Date and eventually the specific GRO Registration Date.
The Birth Event should be recorded as before the end of the Quarter Date, or the Baptism Date if known, until the actual Birth Date is discovered.

[capnkeith]

The Birth Event should be recorded as before the end of the Quarter Date, or the Baptism Date if known, until the actual Birth Date is discovered.

That is what I ended up doing. In the Birth date field I now have bef "baptism date" and the quarter date I have put with the GRO ref in the note field.

Would it be an idea if now the GRO Plugin could be modified to include the quarter date as part of the GRO ref in the Birth note field as well as putting it in the date field.

[tatewise]

I suggest you start a new Add GRO Source discussion thread and refer back this thread.
It should be a fairly easy change to make, but Jane is the Author.

[johnmorrisoniom]

I have all my odd citation dates sorted out now (all typos on a stiff laptop keyboard) but the statistics still show a christened max age of 100. The biggest I had was 31 and I have now changed all ages larger than 16 to adult Christening. However the latest statistics update still shows max christening as as 100.

Screen Shot

Statistics Report.JPG (132.04 KiB) Viewed 11745 times

On an aside , is there any way that the plugin could use the ignore problem marker set by Jane's Plugin?

[tatewise]

Please note that this is NOT an explicit Christening Age as shown in Age, Min., Ave., Max. columns.
It is a calculated Age@, Min@, Ave@, Max@ where the Christening Date is 100 years after the Birth Date.
May I remind you of my earlier suggestion:
Age At
If your Age@Christening is a Fact Query using %FACT.DATE:AGE_AT% qualifier then many Date formats are not supported. A better option is the =AgeAt(FactOwner(%FACT%,1,MALES_FIRST),%FACT.DATE%) function.

An alternative technique would be an Individual Query that calculates the difference between =Year(%INDI.BIRT.DATE%) and =Year(%INDI.CHR.DATE)% and Row filters large values.
Again the =Year() function does a better job than the :YEAR qualifier.

Ignore Problem Marker
A fairly easy option to add would be to enable/disable entire Classes of Exceptions such as all Date Warnings.

I had been thinking about an ignore Exception by Exception option, but put it aside as nobody had asked for it.
I am thinking it would require a new tab that listed the Exception Reports with an Ignore tick box against each one.
It may be trickier to implement than it sounds but I will add it to the wish list.

[johnmorrisoniom]

I Have tried both types of Query Mike, but no christenings with an age @ of 100.

Here is a screen shot of the results using the =AgeAt(FactOwner(%FACT%,1,MALES_FIRST),%FACT.DATE%) function.

Age At results.jpg (133.13 KiB) Viewed 11723 times

As you can see, no Christenings.

[tatewise]

It also has no Burial Age@ 105 so it would be worth checking the other Fact Age@ and compare with Max@ in the Show Project Statistics.

It may also be the way the Plugin calculates Age@ by obtaining the first Date from any Date Range or Date Period to use as the =AgeAt() date parameter.

The equivalent qualifier is :XDATE1 so try =AgeAt(FactOwner(%FACT%,1,MALES_FIRST),%FACT.DATE:XDATE1%

[tatewise]

Another idea is to lower the threshold at which Fact Age is too large is reported.
Then an Exception Report will link directly to the problem Christening.

To do that edit the Plugin at about line 1681 and change if intAge > 120 then to if intAge > 99 then so any Age greater than 99 is reported.

[johnmorrisoniom]

Thanks for your help Mike.
I have edited the christening fact query, and have now found the offending record. Don't know why the original query didn't show it. I managed to pick up a few where I had a christening but no birth record in the process as well.