I would prefer it if the Primary Name fact did not appear at the bottom of the fact listing. I tried changing the fact universally, but it doesn’t show up on the listing. I suggest having an option in the Settings → General Settings that gives us the option to put it at the top of the facts or at the bottom of the facts. For me it fits better at the top around all of the other name items. It would still have the option to change the sort date in case someone wants to move it.
@ljbarney89 if you go in and add a sort date -1 to the primary name fact , it will move the primary name to the top of the list such as date of birth-1
I know a real pain if you have a large amount of people but it’s a work around for now
1 Like
I am already working around it by changing the sort date, but something more permanent and easier would be great.
All facts default to sorting by Date field ~ NOT Sort date
Sort date merely OVERRIDES Date field sorting
SO for Primary Name use Date field ~ NOT Sort date
I don’t think that is well stated. Facts are sorted by SortDate. There is no other sort key. By default, the displayed Sort Date is derived from and identical to many, but not all, of the valid date types entered in the event’s Date field. But the ways Date and Sort Date are stored are completely different from each other and what is displayed. Date is a position coded string unsuited to sorting while SortDate is a number designed for sorting. The Date field allows free text as well as certain date formats. If a user wants to preserve a 'text Date ’ or a valid Date or an empty Date for an event but wants it positioned differently, changing the SortDate is the only option.
Inelegantly worded, perhaps, but Sort date is initially strictly a derivative of Date field entries and ONLY changing the Sort date overrides that “derived” Sort date. So, one SHOULD use the Date field BOTH for the chronology of the Fact -and- for completeness of the Fact and its output in reporting/export.
Most people never add a date to the Primary Name which is why it sorts to the bottom of the list-- the only difference visually between using the date field and sort field is that when you add it to the date field, then the date shows in the date column BUT here is why I said to use the sort field with a -1
No matter how I do it ( without -1), I have some in my test database that when I add a date to the Primary name, the birth fact shows up 1st then the Primary name
And I know that sometimes when I’ve tried this tonite ( without -1), the Primary Name Fact ended up before the Birth Fact BUT not always
interesting…
does it matter if you re run indexes (tool)? or does it always stay that way
Explained many times by users; rarely, if ever, by RM.
1 Like
Indexing has no effect. There are likely several ways, but the most straight forward is to serialize equal sort dates into the order desired (adding -1,-2,-3, …) to actual Sort date. Then, one CAN subsequently elect to delete (remove) those dash endings and they will remain in that serialized same date order EXCEPT for Primary Name… which requires that the -1 remain appended to its Sort date to be shown first amongst same dates. Removing its dash number (after sorting) ̶o̶f̶t̶e̶n̶ ̶r̶e̶s̶u̶l̶t̶s̶ ̶i̶n̶ ̶d̶i̶s̶p̶l̶a̶y̶ ̶o̶r̶d̶e̶r̶i̶n̶g̶ ̶f̶o̶r̶ ̶P̶r̶i̶m̶a̶r̶y̶ ̶N̶a̶m̶e̶ ̶t̶o̶ ̶b̶e̶ ̶t̶h̶e̶ ̶s̶e̶c̶o̶n̶d̶ ̶o̶r̶ ̶t̶h̶i̶r̶d̶ ̶f̶a̶c̶t̶ ̶o̶f̶ ̶t̶h̶o̶s̶e̶ ̶e̶q̶u̶a̶l̶ ̶D̶a̶t̶e̶/̶S̶o̶r̶t̶ ̶d̶a̶t̶e̶ ̶f̶a̶c̶t̶s̶.
1 Like
̶o̶f̶t̶e̶n̶ ̶r̶e̶s̶u̶l̶t̶s̶ ̶i̶n̶ ̶d̶i̶s̶p̶l̶a̶y̶ ̶o̶r̶d̶e̶r̶i̶n̶g̶ ̶f̶o̶r̶ ̶P̶r̶i̶m̶a̶r̶y̶ ̶N̶a̶m̶e̶ ̶t̶o̶ ̶b̶e̶ ̶t̶h̶e̶ ̶s̶e̶c̶o̶n̶d̶ ̶o̶r̶ ̶t̶h̶i̶r̶d̶ ̶f̶a̶c̶t̶ ̶o̶f̶ ̶t̶h̶o̶s̶e̶ ̶e̶q̶u̶a̶l̶ ̶D̶a̶t̶e̶/̶S̶o̶r̶t̶ ̶d̶a̶t̶e̶ ̶f̶a̶c̶t̶s̶T̶h̶i̶s̶ ̶m̶i̶g̶h̶t̶ ̶p̶o̶s̶s̶i̶b̶l̶y̶ ̶b̶e̶ ̶s̶o̶m̶e̶ ̶p̶r̶o̶g̶r̶a̶m̶m̶a̶t̶i̶c̶ ̶m̶e̶a̶s̶u̶r̶e̶ ̶t̶h̶a̶t̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶m̶a̶k̶e̶ ̶P̶r̶i̶m̶a̶r̶y̶ ̶N̶a̶m̶e̶ ̶a̶ ̶h̶a̶r̶d̶ ̶a̶n̶d̶ ̶f̶a̶s̶t̶ ̶f̶i̶r̶s̶t̶ ̶(̶i̶n̶ ̶s̶o̶r̶t̶ ̶o̶r̶d̶e̶r̶)̶ ̶b̶u̶t̶ ̶a̶c̶c̶o̶u̶n̶t̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶p̶r̶e̶m̶i̶s̶e̶ ̶o̶f̶ ̶n̶o̶ ̶D̶a̶t̶e̶ ̶f̶i̶e̶l̶d̶ ̶e̶n̶t̶r̶y̶.̶.̶.̶ ̶t̶o̶ ̶k̶e̶e̶p̶ ̶t̶h̶a̶t̶ ̶f̶a̶c̶t̶ ̶v̶e̶r̶y̶ ̶n̶e̶a̶r̶ ̶t̶h̶e̶ ̶t̶o̶p̶ ̶i̶n̶ ̶a̶ ̶g̶e̶n̶e̶r̶a̶l̶ ̶d̶a̶t̶a̶ ̶e̶n̶t̶r̶y̶ ̶s̶c̶e̶n̶a̶r̶i̶o̶.̶
EDIT
My observation in this and my prior post are wholly \WRONG/ and not true regarding special treatment for this fact. Primary Name can be ordered anywhere similarly to the other facts.
so essentially you have to do version of this ?
to sort “first” (prior to birth date)?
if some, this could be done in batch by SQLITE
Seems to me that, instead the “Sort Date” field, it would be more useful to have a “Sort Order” integer field. Then with programming logic …
- Sort first by fact date
- If no Sort Order value exists, no further sorting beyond fact date
- If Sort Order exists, apply order value within the bounds of fact date. In other words, if you had 3 facts all dated the same, Sort Order would guide which of those 3 was listed first, etc.
- If Sort Order exists on some but not all facts within the bounds of a fact date, those with Sort Order always appear above those without.
Even including the spelling of the Fact name in some sorting considerations ! Or was it perhaps the order facts types are enumerated in an output GEDCOM? I can’t remember, LOL.
EDIT:
Yes, successively adding two facts with the same Date/Sort date and Fact Type names beginning with a ‘B’, like Birth followed by Baptism become ordered alphabetically.
Personally, I add sort dates to all of my no date facts and names using a SQL script that I run every week or so.
It puts those items at the end of the fact listing but in a consistent order that I like.
TMG had some builtin rules for sorting undated tags, but I find my method superior.
There are all kinds of rules one could dream up: birth before death before burial or cremation, marriage after marriage license. Etc etc.
I’d rather that I create the rules than RM.
Maybe RM could add a tool to do these auto sorts. I just rather that it didn’t do it automatically.
And I most definitely want RM to always sort by sort date.