Bruce asked questions about my SQLite3 scripts which Jerry answered very well but not completely accurately nor from first principles. The SortDate field in the EventTable of the database contains a number that looks nothing at all like a date. Today's date is represented by 6762593562815102988; a blank date by 9223372036854775807. The Sort date: field that we see in the Edit Person screen interprets between the stored number and the date format string that we see or enter. The numerical encoding of dates is very efficient because no decoding is required for sorting; the extra system effort is incurred only at time of data entry and display, i.e., one at a time. Indeed, the numerical encoding used is very clever as it allows for many variations of dates with varying precision (to the year, to the month, to the day), various modifiers (about, after, before,...) and date ranges. The suffix numbers allow for 4999 different values that sort earlier than the nominal date but after the day before. The nominal date could be regarded as date-5000; date-0 is equivalent and both are displayed as just date. I wrote these scripts with a poorer understanding of the encoding/decoding algorithms than I have now, thanks to the insights of Steve Turley: see http://sqlitetoolsforrootsmagic.wikispaces.com/Dates%3E+SortDate+Algorithm . I intend to revise them to handle modified and range dates. Currently, the favoured script is SortDateSameDayOrderCustom.sql at http://sqlitetoolsforrootsmagic.wikispaces.com/Dates+-+Same+Day+Sort+Order ; the first script was superseded and shown only to gain insight into the second, more complex one. The scripts were intended to solve problems that bothered some people with minimal impact on their database so the current one only modified SortDate values when there was a match with another event in the 'natural' list. But it demonstrates a principal that could be applied at time of data entry and import instead of after the fact: the assignment of the unique offsets to preclude potentially many instances of objectionable disorder. There are many reports and screens that currently rely on the SortDate values for order and these need not be revised to support some additional tie-breaking mechanism. There are only two areas I can think of that would be revised to assign the SortDate offsets: data entry and data import. ------------------------------------------------------------------------------------------------------ > How does it handle a birth and death where neither has a date (and > therefore no sort dates). Exactly the same as if they were dated. The stored SortDate is numbered and receives the same offsets but no value is displayed. The user cannot and need not enter a date string that produces the same SortDate value but would put in some valid date as he must do now if it was necessary to place the events in some logical order in the context of other dated events. ------------------------------------------------------------------------------------------------------ > How does it handle a situation like this? > Married 1800 > Born (no date) > Died (no date) The script does not modify the SortDate values of family events but the principal can be applied just the same. The principal does not change the order of events with different dates. If the RM output before the principal is applied was M.1800, D.____, B.____, then the order after would be M.1800, B.____, D.____. ------------------------------------------------------------------------------------------------------ Not asked, but how does it handle a situation like this? Born 1900 Died 1900 Because the sort dates are equal, the current script changes the sort date for the birth fact to 1900-20 and the sort date for the death fact to 1900-70. If the program were revised as I have suggested, these would be the automatically generated sort dates, regardless of any other event on the same date, thus inherently providing a natural sort order. ------------------------------------------------------------------------------------------------------ Not asked, but how does it handle a situation like this? Born 1900 Died 1910 Because there are no sort dates that are equal, the script does not change the sort dates. With the software revision I have proposed, the sort dates would be 1900-20 and 1910-70 , respectively. Tom