* Query to find all dates with year modifier

[LornaCraig]

I am trying to construct a query to find all date fields which contain a year modifier: that is, all dates which have been entered with the year in the format 1715/16, indicating 'double dating'.

I want to do this because I think when I first started using FH several years ago I may have wrongly entered some dates as double dates which were post 1752 or which didn't fall between 1 January and 24 March, so double dating didn't apply.

I'm not having any success - can anyone help?

ID:6709

[Jane]

I can't think of a way as containstext does not spot the '/' in the date field.

You could very easily write a plug in for this. Have you tried plugin writing yet?

[delwoodman]

Lorna:
A fact query with the following filter works for me (version 5.0.7)

Derek

[Jane]

Well done Derek, I assumed dates did not have contains text.


Anyway I had written the Plugin so I'll put the link here, but I won't bother posting it to the store.

https://www.dropbox.com/s/bik9yf5st9l5z ... tes.fh_lua

[LornaCraig]

Many thanks to both Derek and Jane.  I had been trying to use an individual query rather than a fact query.

I have run both the query and the plugin and was initially puzzled by a slight discrepancy in the results.  This turned out to be because the plugin picks up double dates in the 'Entry Date' field of the Source pane, in addition to fact dates.  I don't know whether it would be possible for a query to pick that up - if not, it might still be worth posting your plugin to the store, Jane.

Thanks again to both.

[PeterR]

You could have a Fact query with an additional Row Filter to the one above, using the following expression:

Code: Select all

%FACT.SOUR[1].DATA.DATE%

You would also have to add a corresponding additional column.

The problem is that you would also have to repeat additional row filters and columns to cope with Facts having more than one Source, e.g.:

Code: Select all

%FACT.SOUR[2].DATA.DATE%

Thus Jane's Plugin is certainly preferable.

[tatewise]

Yes, this problem is really annoying.
FH should have a wild card index that allows all instances in a Row Filter to be included.
Similar to the Text Scheme looping index [1+] feature.

[LornaCraig]

One further thought: I have a few Multimedia objects with double dates (images of parish records).  I have identified these easily because they are linked via Source records to  individuals who have double-dated facts.  

Could the plugin be amended to pick these up too?  I don't actually need this refinement because I have already identified them, but it might increase the potential value of the plugin.

[Jane]

Media can be done easily, if you fancy changing the allitems loop code (lines 20 and 21) to

Code: Select all

for ptr in allItems('INDI','FAM','OBJE') do
        if fhGetValueType(ptr) == 'date' then

That will do it or just download the plugin again.

[LornaCraig]

Thanks Jane, I thought I had found them all but that flushed out a couple more!

[Jane]

I have done an extended version of this one called

Date Search and Return Result set which searches for

Qualified Dates
or
Double Dates
or
Dates which match or overlap a selected date.

If anyone has time to take a look it can be downloaded from

https://www.dropbox.com/s/luqrfh375xymf ... Set.fh_lua

[LornaCraig]

Thanks Jane, this extended version of the plugin meets a need I didn't know I had.  It has shown up a few inconsistencies in the use of the 'estimated' and 'approximate' qualifiers and prompted me to change a few 'est' entries to 'app'.

I can see that it could also be useful for searching for any events on a particular date or in a date range. I wonder if a refinement might help here.  For example at present if you search for 1800, or the range 1800 to 1805, the result set includes dates like 'before 1945' because that overlaps the date/range searched for.  I might be useful to have another option to return only dates which match or fall within the date/range searched for.

[Jane]

I wondered about the Before and After dates. They are always a problem especially if viewed, as the plugin does, in isolation. I'll have another think about them.