For me, ascending/descending sorts by date (double left-clicking the column header name) such as Birth Date or Death Date sorts the People List view with empty dates both above and below non-empty dates. Anyone else see this? Wondering why the empties aren’t all sorted together. Thanks.
For me, those sorted to the top have no birth fact entry. Those sorted to the bottom have a birth fact entry with a place of birth but no date.
1 Like
Thanks for that observation! In light of that, there seems to be a need for a clarification as to whether that is intended as part of the sorting feature.
1 Like
Until reading this thread, I had not paid attention to the way the sort feature works on the “Birth Date” column. Additional description would be helpful and the current behavior seems quite useful as long as users know what to expect.
It seems optimal to distinguish between people lacking a birth event and people with a birth event that is missing a date. Finding all people without a birth fact (or with an incomplete birth fact) is as simple as clicking on the “Birth Date” column heading… no custom search or group definition required.
Also, as an aside, on mac there is no dbl click action. A single click on the “Birth Date” column heading toggles the sort order, alternating whether records missing a birth fact appear at the top or bottom of the list.
yes – I had not noticed the way incomplete dates are sorted before
A little unclear why the sorting on “abt” is not all together – might have to do with the SortDate field also be used.
I went into the People’s List and removed all of the options except BIRTH–again it has the ones with a birthdate in the middle in chronological order and the blank ones at the top and the bottom-- what I figured out is that the ones at the TOP had absolutely NO BIRTH FACT AT ALL-- the ones at the BOTTOM had a birth fact BUT NO DATES JUST WHERE BORN ( Germany, IL etc)–which is kind of strange sine I took place of birth off the list…
That is typical of spreadsheet applications with text and numbers combined.
Is it clear whether the sort is using the sort date or the RM date?
It also get complicated when there are multiple birth date facts for a person.
1 Like
not typical when “abt 1824” (exact same string) gives multiple different results – therefore is something beyond that field. Done spreadsheets for 30 years and even wrote Bubble sort routines back in the 80’s.
This is unexpected by string sort
good point – my guess it might use the order entered (RecID for the event)
The SortDateOrder has a very complex algorithm.
Yes, I think the sorting is done on the unvarnished, encoded Date field but there are exceptions that I have not yet figured out. One is when there is more than one Birth event - it looks like the Primary setting is disregarded and maybe it is the row number that determines which one is displayed.
Correction, not sorting on the whole encoded Date field but substring of it containing the 1st instance of the format “yyyymmdd”. And looking at only the first Birth record (not the earliest Date) in the table for a person as illustrated in this comparison between RM9 and a SQLite query for a set of Births reported as being in 1887.
The query I used to get a matching result is this:
SELECT OwnerID, Date, Min(EventID), SortDate, IsPrimary
FROM EventTable
WHERE OwnerType=0 --Person events
AND EventType=1 -- Birth event
GROUP BY OwnerID -- Rec# or RIN in RM
ORDER BY SUBSTR(Date,4,8) -- yyyymmdd extracted from 1st instance in Date
--ORDER BY SortDate
;
In this example, the order from the query was no different using SortDate. However, I confirmed that SortDate has no bearing on the order in the People List by changing the SortDate for RIN 440, the last in the set, to 1887 which would have brought it to the top of the set if SortDate was the key. It did not budge.
Therefore, SortDate and Date modifiers such as Abt, Bef, Aft and, probably, Range have no bearing on the order presented. Only the lowest record number in the EventTable is brought out whenthere is more than one Birth event for a person and, also, the Primary flag is ignored.
The ignoring of the Primary flag in the People List results in possible inconsistency with the Summary pane and the sidebar Index. Here’s an example where they show the date “1887” while the People List shows “Abt 1886”. The record having “1887” was added after “Abt 1886” and is marked Primary.
1 Like
here is my result of the same script .
Yes, it’s a simpler set than mine having just year-only dates and instances of the “About” modifier (the “.A” following “18870000”) mixed in with unmodified ones (“…”). Because sorring is only on the “18870000” part, the results come out by default in the order they are in in the underlying table.
Note also in my example the Quarter date whose encoded Date field begins with R instead of D. Yet it is positioned strictly on the value “18870200”. But the 02 does not signify February as it does for a D Date; rather, it mean 2nd Quarter whose last month is June. RM People List ignores both suffix and prefix Date modifiers.
Nice job.
I don’t understand RM Inc.'s reluctance to use the sort date for sorting.
Here, in ordering children and spouses. Maybe other places too?
I would not think it advisable to consider the SortDate in the sort order for a column in the People List because it really is intended for ordering the events of one person, not for one FactType for multiple people. What use case are you thinking of?
I do think that the Quarter dates should be encoded differently. Why should the “Dec Q 1903” be encoded “19030400” which sorts it ahead of “1 Apr 1903”? Why not encode it “19031200” or “19031100” which would sort it among other dates that are actually in the Oct-Dec quarter? Or even “19031115” to sort it into the middle of the period.
I think the Quarter Dates are a special instance of a Range Date which I suspect is sorted on the 1st date in the range. The Date “1903-1906” likely sorts on “19030000”, not on the middle of the range, “19050000”.
There are similar anomalies in the values automatically assigned to SortDate from the Event Date.
1 Like
Good question – at least have option to choose were you prefer.
I suspect the logic or reasoning is because too many average users would not properly make yes of the SortDate fields.
Kevin
Tom- I’ve never heard of Quarter dates in RM. No mention of them in online help.
You aren’t referring to Quaker dates, are you?
I’ve written about my preference for the use of sort dates whenever items need to be sorted in other places.
No. There 4 Quarter dates:
Mar Q - 1st quarter
Jun Q - 2nd
Sep Q - 3rd
Dec Q - 4th
I’m familiar with them both from earlier versions so it’s an oversight that Quarter dates are not covered in Help. They are commonly used in recording BMD from UK GRO Indexes. See
Here’s the earliest indication that both Quaker and Quarter date entry was a new feature in RM4.
http://blog.rootsmagic.com/?p=17