Jump to content


Member Since 18 Nov 2005
Offline Last Active Yesterday, 01:55 PM

Topics I've Started

Another Gedcom Loss of Data

16 August 2019 - 01:16 PM

I only noticed recently that the Standardized PlaceName and Abbreviated PlaceName data gets dropped on Gedcom transfer even with RM Specifics checked.


This is RM Specific data which should be protected so I believe this is a bug. Rootsmagic users who have painstakingly entered such data to improve their database will unwittingly lose all that hard work on Drag&Drop or Gedcom transfer when they are maybe only trying to solve some other database problem.


I will be interested to hear the comment of Rootsmagic but I can hardly see this as "operating as designed" without ever warning users of the data loss?

Inaccurate Sorting of Estimated Dates - Sort is skewed

31 May 2019 - 07:47 AM

I'm travelling with patchy connectivity at the moment but couldn't find this acknowledged as an issue before.

The sorting of approximated dates popped up on Facebook this morning, at present I don't find these sort dates an accurate estimation usually being skewed to the begin date.
For example a Bet date applies the earliest date as the sort date not the MID. So for an entered date of Bet 1 Jan 1900 and 31Dec 1900 Rootsmagic will apply 1 Jan 1900 as the sort date and not 2 Jul 1900. This is also true where quarters are used were Q1 1900 will effectively sort as 1 Jan 1900, this is not the displayed sort it is the effective sort date. All my estimated dates are personally refined and reviewed often in line with available information.
The skewing of sort dates for Bet dates is not terribly noticeable in small databases but it can be very deceptive in larger databases. I have a large database and presently work my own solutions to this but shouldn't need to. Within Rootsmagic I would suggest providing a user option regarding how to calculate and apply sort dates for approximated dates.
I know RM7 has been programmed this way so I would assume the programmers know how these sort dates are calculated, however it is not an accurate estimation to sort on and becomes very evident within a large database.

NameClean & PlaceClean need to learn (not a problem)

24 April 2019 - 07:30 PM

I just tried NameClean and it counted over 6000 of my manes had problems where they do not.


It seems obvious where NameClean and PlaceClean continue to report high counts of potential problems despite problems not existing that the feature becomes useless and will be ignored by users.


NameClean and PlaceClean need some learning capability towards international acceptable standards from the user to build on what is otherwise a useful utility. The ability to apply defaults would still be a welcome option for a thorough analysis of the Name and Place Data.

Duplicate Search Merge Routine NEW and revisited wishes

27 January 2019 - 08:33 AM

I think I’m all wished out but I don’t remember adding this to the long list of enhancement requests.

As I progress in my use of Duplicate Search Merge I widen the parameters firstly by unclicking the Compare Birth and Death Places, then increasing the year span and maybe using Soundex. Currently session to session I need to remember the last parameters I used and it would be very useful if this could be remembered by Rootsmagic so it helps and grows with my preferences, I don’t believe I have put this suggestion forward before. This could be easily restored by adding a ‘Return to default’ button.

This very useful Routine could also benefit from the incorporation of a Duplicate Facts find option where the user specifies a year span. For example specifying Zero would find a record which has a Census record dated 1901 and a duplicate fact dated 31 Mar 1901 for user resolution. This has become a much wished for feature on various forums maybe exacerbated by online interaction.

What has been put forward and cited many times before is the current danger of merging and leaving this routine without tidying up the merged individual resulting in residual duplication in the database. I would suggest, at least an option checkbox, to go directly to the Edit Person screen following any merge.

I believe I have put this forward before but Rootsmagic does not appear to compare the description fields highlighting them green on both sides, see below. Rather than over complicating matters and slowing the comparison process this might be worth adding as a non default additional option for those who wish to use it.

Also put forward before is the requirement for a more informative and detailed DSM display more akin to Timeline Views so users are better informed. Currently I often note possible duplicates by RIN on a piece of paper and then compare side by side in Rootsmagic later for more detail which is not so easy just by clicking the Edit person button alternatively on each primary and possible duplicate person.

Again already put forward is a wish to enable sorting this screen by primary person name which would be useful especially in large databases and name studies.

Already put forward is the request to restrict the scope of DSM to the contents of any Names Group which would enable the user to create a group of those with the Surname ‘Doe’ and any fact place contains ‘Pennsylvania’ and occupation contains ‘blacksmith’ or whatever.

Remembering the last used window size is a generic wish across Rootsmagic so should not need to be repeated here.

The existing Duplicate Search Merge routine forms the basis of what I believe to be a very powerful and much desired feature but it does require much improvement and thought to reveal that power which I hope the developers recognize.