I have many ancestors who were born and baptized on the same day. In RM9, sometimes it displays birth B4 baptism, sometimes baptism B4 birth. I get around this by using “before” in the birth sort date when needed, but wondering if others have expereinced the same problem and have found another solution or have determined what is triggering the display order. It does not seem to matter if the events are marked “primary” or not. I can’t figure out what is triggering the display / sort order in the person view.
I usually put date-1, date-2, etc. in the sort date field.
1 Like
To the best of my knowledge, RM has always acted this way. At least one of their competitors sorts birth/baptism and death/burial pairs into the correct sequence even with identical dates. They’ve probably added a “natural sort sequence” key into the fact type. That shouldn’t be too hard to accomplish but I don’t think that we’ll see that happen.
Correct. RM has always acted this way.
If I remember correctly, the rationale for the behavior was the the developers did not want to do anything that would interfere with the user’s control and flexibility in ordering events in a way that met the user’s needs. My apologies if I’m not remembering the rationale correctly.
It has always seemed to me that RM could do a better job of sorting events without in any way limiting the user’s control and flexibility. And before we go any further, let’s acknowledge that RM’s sort dates are a great feature. I would not want to get rid of them or replace them or subvert their utility in any way. And before we go any further let’s make note of the fact that the default sort date for a fact is the same as the date for the fact. This discussion is usually framed in terms of what to do about same date facts such as a Birth fact and a Death fact and a Burial fact which all have the same date. However, because RM actually sorts facts based on the sort date and because the sort date defaults to the date for the fact, this discussion should really be framed in terms of how to sort facts with the same sort date.
I would contend that if same sort date facts could be sorted automatically into some sort of rational order, then for the most part sort dates would not be be necessary. Sort dates should still be supported, but even so some sort of rational tie breakers should be available by default and with user control to change the default. Therefore, if a user did specify different sort dates for same date facts then these rational tie breakers would not come into play at all. The user would still have total control over fact order via sort dates.
I would picture the same sort date tie breaker as being a simple list of fact types that would default something like the following. The list is in tie breaker order. Note that these are all built in fact types.
Birth
Christening
Baptism
Death
Burial
Then as a user, I should have the ability to amend the tie breaker table as follows. That’s because I have a user defined fact called Parents that I always want to appear immediately after the Birth fact. I give the Birth fact and Parents fact the same date and different sort dates. I’m sure that other users might have other facts that need the same sort of treatment.
Birth
Parents
Christening
Baptism
Death
Burial
The notion of tie breakers for sorting is scarcely new. I learned how to do it back in the mid-1960’s, and I think the idea was already ancient even way back then. So let me end by repeating that this fact ordering table would only come into play for facts with identical sort dates. No ordering specified by the user via sort dates would ever be changed.
1 Like
SQLite procedures were developed by myself and others years ago that demonstrate the feasibility of ‘natural’ or custom sorting of same-day events. It was hoped that RM developers would adapt them under the UI. While that has happened for a few other such SQLite procedures, we’re still waiting for this one…
https://sqlitetoolsforrootsmagic.com/dates-same-day-sort-order/
1 Like
The competitor that @rwcrooks referred to actually uses something called ‘Normal Time Frame’ AND still offers sort dates. In the ‘Normal Time Frame’ you have groupings such as Birth, Shortly After Birth, Death, Marriage, and Post-Marriage among others. These can be assigned to custom facts too. Then the sort dates still exist for fine tuning the sorting for an individual.
I agree that the “sort date” field is great and am not suggesting any changes. But I am still confused on what I am doing that sometimes it sorts birth before baptism, and sometimes baptism before birth. There is some logic thread that I cannot understand. What is the software using to determine the sort order? I’d like to know what I should do as I enter data to have consistent outcomes, instread of needing “before” in the sort date field sometimes and not others.
The “tie-breaker” for events having the same sort-date is the record number in the database’s EventTable, i.e., the order in which the event records were created. Thus, a convoluted method of rearranging two would be to delete the first and recreate it. Editing the sort-date is much easier.
1 Like
TomH, Thank you! I thought that might be the case. You made the data geek in me very happy!
And it would help to put facts without dates in an acceptable order. Like undated residence, occupation, education and others before death.
Some would argue that the current clustering of undated events separately from dated ones is desirable or preferable as they draw attention more effectively. Maybe it would be better still to leave it as is and add the ability to drag and drop events into an arbitrary order.
1 Like
Some would argue that those people are a minority. However, no matter how you slice it, the current system could always be improved. I have many undated facts that I would like intermingled, such as Findagrave (a custom fact), and I have other dated facts, such as Census and my custom ResAt fact that I want sorted to the bottom of the list. So far I have managed this with sort dates.
Thanks for the tip. Ran the On This Day report and had an instance of Death then Birth - child was stillborn. Edit screen was fine (B then D). Playing with dates did not change the report. Deleted the Birth, recreated it and report is correct now. Bravo.
That it was the Birth event you deleted and recreated anew to get the right order is surprising. I expected that would result in the wrong order but it’s possible that one output could be in ascending order of record number and another in descending order.
It’s also possible that the On This Day report ignores Sort Dates.
I think that’s more likely to be the issue.
Could be as the Month & Day print in the header while year is in details. Before TomH fix tip:
Delete Birth event & Recreate it give this:
Give it a try and see what sql shows. Thanks.