If there are facts with the same date, I use the actual date and add -1 to identify which item should come first; then date -2.
2 Likes
More natural or logical or user-determined order for events on the same date has been a very old request that led to these oldish outboard workarounds:
https://sqlitetoolsforrootsmagic.com/dates-same-day-sort-order/
You can add a -1 to the sort date to change the order. Try adding it to the census sort date and see if it moves it up. I did it with a Census and Residence fact and they switch. which ever has the -1 shows first.
Perhaps I miss-understand the issue but Bruce mentioned that there is both a date field and a sort by date that can be used to control the order of items. See attached screenshot of a person’s edit screen right sidebar.
Correct. The fact order is first based on the date field and the sort date defaults to the date field. But that doesn’t solve all problems.
First of all, there can be facts that have the same date such as a person being born, dying, and being buried all on the same date. Since the sort date defaults to the date, all three facts will have the same sort date. The order of the facts is effectively random under these circumstances, and the sort dates may need to be adjusted to place the facts into the correct order. One way to adjust the sort dates is with things like the -1, -2, and -3 suffixes. But if somebody was born, died, and buried on 10 Oct 1903, then you can use 9 Oct 1903 as the sort date for the birth, 10 Oct 1903 as the sort date for the death, and 11 Oct 1903 as the sort date for the burial if you wish.
Second of all, there can be facts without dates. This is not really common, or at least it shouldn’t be. But if it happens and the order of facts matters, then again sort dates may need to be entered to place facts into the correct order. Sort dates do default to the date, but the date does not default to the sort date. You can enter a sort date for a fact without a date and the fact still will not have a date.
Third of all, there can be facts with date ranges. The date ranges usually do not cause problems with fact order. But if they do - for example if there are two different facts with overlapping date ranges - then again sort dates may need to be entered to place the facts into the correct order.
1 Like
Well, well, my initial posting has kicked off quite a discussion. Time to step back in and maybe clarify my concerns…
First off I am aware of the ‘sort date workaround’ and do use it occaisionally, it works, but feels like a fudge.
Whilst it would be nice to have a more sophisticated sort order option i.e. date and then fact type, what I was really complaining about was the randomness of how it works and lack of consistency. I don’t mind if I have two facts with the same date eg Census and Occupation what order they come in as long as that is the same within the same individual and across multiple individuals.
An example may better explain this …
I have two facts (Census and Occupation) for two different dates (1881 and 1891), now I don’t mind whether Occupation comes before or after the Census but I expect it to be consistent. Instead what I see (in some cases) is…
1881 Census
1881 Occupation
1891 Occupation
1891 Census
Now you might claim it depends on the order you put them in (I’m not sure it works that way), in all the cases I have entered the Census fact first and the Occupation fact second, so that seems to have no effect.
I just want the display of facts to have a consistent and understandable reading order and going through hundreds of records to fudge it to be consistent through use of the sort date is quite frankly too much of a task and waste of time.
RM does not handle this situation without sort dates. It’s just like it doesn’t handle same date birth/death/burial facts without sort dates. So your choices are sort dates or else your facts are not in the order you wish just from their dates and fact types.
1 Like
The order is not random. It is based on which one you edited last - I can’t remember if the last edited becomes the top one or the bottom one, but that is the rule the program is using to sort your data.
Incorrect. It is governed by the Sort Date. Else why have such a field?
I think the context of the response is “what is the order of same date facts in the absence of user specified sort dates?”.
The first part of the answer is that in the absence to user specified sort dates, the sort dates will be the same as the fact dates and same date facts will also be same sort date facts.
The second part of the answer for me is that I am not sure. I don’t think it is truly random. But if not truly random, then what is it exactly?
And as Tom said, the correct user response is to enter sort dates of their own choosing rather than accepting the default sort dates.
Then that has to be the order that the event records were created in the EventTable; nothing to do with any of the date fields: Date, SortDate, UTCModDate- only the primary key EventID.
EDIT: I just confirmed that is the case with a clean, new database with one person having a Death and Burial on the same date. To begin:
EventID
1 Death
2 Burial
That is the order in which they were displayed in Edit Person.
I edited the first and set its EventID to 3, so:
2 Burial
3 Death
…is the order in which they are displayed.
For those unfamiliar with the table concerned, it looks like this:
EventType 2 is Death and its UTCModDate (Date last edited) is earlier than EventType 4 (Burial) because that record was created by RM first (originally EventID-=1).
I always use “sort dates” for all facts, because I want my facts in a certain order… i.e. I use a Ref # on all people and want that fact at the top. I also like being able to control this versus it being automatic or random within the program. I just use years most of the time. John