There would be no degradation in the detectability of typo errors with the enhancement I propose to the auto-generation of the SortDate on Date entry, Date edit, and GEDCOM import that would resolve the current disordering of same-date events such as Birth and Death. Currently, the two events dated 12 Jan 1912 both receive auto-generated SortDates of 12 Jan 1912. Because the SortDates are identical, RM will output them in an order that relates to the order of record creation, which, as often as not, is the wrong way round. The enhancement would auto-generate the Birth SortDate as 12 Jan 1912-10 and the Death SortDate as 12 Jan 1912-70. RM sees these as different dates and will sort them chronologically, regardless of the order in which their records were created. The offsets of -10 and -70 (or whatever Bruce deems to be appropriate) leave plenty of room for other possible same date events to be interposed in the right order, using a different offset (up to 4999, I believe). The user is free to override these SortDates with different values, just as he/she can currently. All Birth dates would automatically be treated with the same offset, regardless; likewise Death dates, whether or not any other event occurred on the same date. If unique on that date, the offset has no effect on the event order. This enhancement does not dictate or change anything that the user currently has under his control. Rather, it relieves the user from having to find instances of same date events for which he/she must fiddle the SortDates to get the order to be natural and logical. I cannot see anything about it that could be counterproductive or counterintuitive. I do see positive benefits and a potential educational value in introducing the use of the SortDate offsets of which many users are completely unaware. Tom On 2012-12-25, at 7:20 AM, "Jesse Davis" <jespat@verizon.net> wrote: > The way it is done now helps catch typo errors quickly. Otherwise, they might stay until someone else catches them. > Merry Christmas. > J. Davis > >

Tom, You have been saying this for a long time. I see no relationship between the order in which the birth and death items are entered and which event is displayed first in the edit person window. No matter which I enter first, Death seems to float to the top every time as long as they have the same dates. I know, I can enter the sort date and it is no problem for me, but I think you are mistaken about the first entered being listed first. Alfred ========= Tom Holden wrote: > cutCurrently, the two events dated 12 Jan 1912 both receive auto-generated SortDates of 12 Jan 1912. Because the SortDates are identical, RM will output them in an order that relates to the order of record creation, which, as often as not, is the wrong way round. > > cut > > Tom > > >

DARN! I am mistaken AGAIN! You were right, only I was reading it backwards. The lase entered item is on TOP, not in the order it should be Sorry about that Tom Alfred =================== Alfred wrote: > Tom, > You have been saying this for a long time. > I see no relationship between the order in which the birth and death > items are entered and which event is displayed first in the edit person > window. > No matter which I enter first, Death seems to float to the top every > time as long as they have the same dates. > > I know, I can enter the sort date and it is no problem for me, but I > think you are mistaken about the first entered being listed first. > > Alfred > ========= > > > Tom Holden wrote: > >> cutCurrently, the two events dated 12 Jan 1912 both receive auto-generated SortDates of 12 Jan 1912. Because the SortDates are identical, RM will output them in an order that relates to the order of record creation, which, as often as not, is the wrong way round. >> >> cut >> >> Tom >> >> >

I have been a database programmer for many years. The problem associated with the display order of like items is common in all systems based on a database, ie NOT specific to RM. When data is selected from the various database tables it is done so randomly (by default) - not even in data entered order AND not always in the same order - unless there is also an explicit sort request. Then the problem only occurs when there are like items based on the sort request, ie two dates the same. Hence the need for an additional sort item in RM - the Sort Date. Whilst this discussion has centred around BMD events it is also an issue for any event type where there are multiple events on the same date, ie census, residence & occupation. Unless explicit sort dates are used these three events will occur in random order every time they are displayed. David -----Original Message----- From: rootsmagic-users-bounces@rootsweb.com [mailto:rootsmagic-users-bounces@rootsweb.com] On Behalf Of Alfred Sent: Thursday, 27 December 2012 2:00 PM To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth, death and burial events when all occur in the same year Tom, You have been saying this for a long time. I see no relationship between the order in which the birth and death items are entered and which event is displayed first in the edit person window. No matter which I enter first, Death seems to float to the top every time as long as they have the same dates. I know, I can enter the sort date and it is no problem for me, but I think you are mistaken about the first entered being listed first. Alfred ========= Tom Holden wrote: > cutCurrently, the two events dated 12 Jan 1912 both receive auto-generated SortDates of 12 Jan 1912. Because the SortDates are identical, RM will output them in an order that relates to the order of record creation, which, as often as not, is the wrong way round. > > cut > > Tom > > > =================================== RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS WISH LIST: http://www.rootsmagic.com/forums/ BLOG: http://blog.rootsmagic.com/ ------------------------------- To unsubscribe from the list, please send an email to ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

> There would be no degradation in the detectability of typo errors with the > enhancement I propose to the auto-generation of the SortDate on Date > entry, Date edit, and GEDCOM import > that would resolve the current disordering of same-date events such as > Birth and Death. I seldom disagree with Tom, but I'm going to disagree ever so slightly on this one. I do agree that the problem can be addressed without any degradation to the detectability of typo errors. I also think the problem can be addressed without causing any harm whatsoever to the way users operate who prefer to insert their own sort dates. The misunderstanding is that when some of us talk about putting things like birth/death/burial in proper order, most of us do not mean that it would be unconditional. For example, if you had two birth facts with dates of 1899 and 1901 and a death fact with a date of 1900, then the facts should appear as follows. birth 1899 death 1900 birth 1901 Obviously, something is wrong with this data, but I'm certainly not proposing that by default the facts should appear as follows. birth 1899 birth 1901 death 1900 To do so would be to put 1901 before 1900, and that shouldn't happen by default no matter that a birth fact should precede a death fact if the data is correct. I'm simply saying that the following should not happen by default. death 1900 (with a sort date of 1900 as provided automatically by RM) birth 1900 (with a sort date of 1900 as provided automatically by RM) Instead, the following should happen by default. birth 1900 (with a sort date of 1900 as provided automatically by RM) death 1900 (with a sort date of 1900 as provided automatically by RM) The place where I disagree slightly with Tom is that I think the above could and should be accomplished without the program itself making any changes to the sort date. In other words, I don't think the following is necessary. birth 1900 (with a sort date of 1900-1 as provided automatically by RM) death 1900 (with a sort date of 1900-5 as provided automatically by RM) I can see how users who prefer to insert their own sort dates might be upset if RM inserted sort dates such as 1900-1 or 1900-5 automatically. Also, I think that the following should not happen by default. death (without a death date or a death sort date) birth (without a birth date or a birth sort date) Rather, the following should happen by default birth (without a birth date or a birth sort date) death (without a death date or a death sort date) And a text date with a default blank sort date should be treated exactly like a blank date with a blank sort date. It seems to me that if it was done this way - as a tie breaker only operating behind the scenes as a part of the sort of the facts, without any automatic sort date changing at all, and totally honoring any and all sort dates entered by the user - that everybody should be happy and that there shouldn't need to be an option to enable or disable this new automatic sorting feature. Sorts use tie breakers all the time. Why not RM when it is sorting an individual's facts? And a tie would be when a sort date for one fact exactly matches a sort date for another fact, or when a sort date for one fact is blank and the sort date for another fact is blank. Jerry