* Problem with queries on name parts

[JonAxtell]

Posting this to check if I am doing something wrong or expecting FH to work logically, or if it's FH that has a bug. I suspect the latter.

I'm doing a query which in common garden format used by every other system in the world would be something like
'surname is Axtell AND marriage date is NOT null AND spouse's given name is null'.

This is to get a list of all the spouses of an Axtell whose first name I haven't recorded as I haven't cross-checked the marriage index entries. I've gone through my Axtell marriages and only recorded the spouse's surname (where available) on my first pass.

I've tried the following query

Code: Select all

Add if %INDI.NAME[1]:SURNAME% matchs 'axtell'
Exclude if %INDI.FAMS>MARR.DATE% is null
Exclude unless %INDI.~SPOU[1]>NAME[1]:GIVEN% is null

This should build a list of Axtells, then remove all those who didn't marry, and then remove all those whose spouse's given name is not empty. However it doesn't work and produces a list where the spouse's name is not known at all. Note that I asked for the GIVEN name of the spouse to be null, not the whole name.

After a couple of hours of frustrating trial and error because of FH's idiosyncratic query syntax I managed to get the result I wanted with the last line of the query being

Code: Select all

Exclude unless %INDI.~SPOU[1]>NAME[1]:STORED% begins with '/'

. Not a straightforward way of getting the result I wanted, and only possible because I understand the Gedcom format and it depended on the fact that a name with no given name and only the surname starts with the '/' character and no given name ever uses the '/' character.

So, should querying if a given name is empty only work if the whole name is null or if only the given name is null?

ID:2881

[Jane]

I suspect it's probably a limitation and probably is null is being confused by the fact that NAME:GIVEN_NAME is not a field in it's own right.

I did find that

%INDI.NAME[1]:GIVEN_ALL% matches

with a blank parameter does work correctly and might be easier to read when you come back to the query next time.

[SimonOrde]

Jon

the reason that your query failed is because Family Historian does not consider a given name to be NULL if there is a Name field, even if it does not contain a given name.  Instead, in this situation, it treats the given name as an 'empty string'.   Your query would have worked if instead of making the given name check 'is null' you had made it 'matches ''' (i.e. left the value to match blank).

It may seem that FH is splitting hairs here, but the difference (or lack of one) between Null and an empty string is actually a much-discussed topic.  Some databases treat them as the same. Most don't.  The SQL standard is that they should be treated as different.  Type 'Null empty string' into Google if you want to read up on it.

[JonAxtell]

Thanks Simon, that explains it.

I think I missed out on the matches a value item method having tried so many different methods I probably got confused as to what I had tried and what I hadn't as it wasn't straightforward and I was getting frustrated.

I do understand that difference between a null string and an empty string as I'm a programmer of 20 years experience, however I would be surprised that a typical family historian would understand the difference. Keep the programming concepts inside the program, not exposed to the user who is generally not a programmer.