Jump to content


Photo

Duplicate Search Merge within Named Group

dsm merge duplicates

  • Please log in to reply
4 replies to this topic

#1 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 2315 posts

Posted 12 November 2013 - 05:20 PM

Duplicate Search Merge is a great feature but It becomes a little less effective as database size grows. An easy way round this would be to export a subset of families and work them in a separate database but you then risk the broken family links and possible dropped information in gedcom.

What I would like to see added to the Duplicate Search Merge selection screen is the ability to select a Named Group to work solely within. The user could build the Named Group based on family names, event information and family geographic location. As you would now be working within a much smaller set of individuals it would be possibly to widen the Birth and Death Year spans without terribly adverse effects.
Software Comparisons - Place Management - How other software packages stack up.
Media Gallery (a critical look) - Written when RM4 was introduced but still applies today.

Relaxation is the key to life and this is where I get some time to relax and catch up on my hobby and research s the key to life and this is where I get some time to catch up on me genealogy work and research

#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 3885 posts

Posted 13 November 2013 - 01:16 PM

So I'm trying to picture this. You select to only work with a named group in duplicate merge search. But, what if the duplicate is outside of the named group? So I guess you want to search just a list of people and find any of their duplicates. Just wanted to clarify this before I add it in the tracking system.
Renee
RootsMagic

#3 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 1113 posts

Posted 13 November 2013 - 05:48 PM

So I'm trying to picture this. You select to only work with a named group in duplicate merge search. But, what if the duplicate is outside of the named group?


I don't want to hijack Vyger's thread, and my vision of how this would work might be different than his. But I will proceed anyway.

It seems to me that Vyger's wish is a prime example of the need for Named Groups to work in any of the main views, not just in People View. So bear with me and suppose just to be supposing that such a feature were available. Here's how it would work.

There is already in People View a button (really, it's a dropdown) that defaults to Show Everyone. If you click Show Everyone, there is a dropdown that lists all your groups if you have any. You can select any of your groups, and subsequently only individuals in that group appear in the People View pane. So we start with the idea that the same button or dropdown option were also available for Pedigree View, Family View, and Descendant View. I'll have to think a little bit about whether the option makes sense WebSearch View or TimeLine View, but it probably does.

More importantly, we continue with the idea that when one of the main Views has been restricted in this manner, the rest of RM would also see only those individuals in the chosen group. So for example, RM Explorer would only search within the group, a GEDCOM export of "everybody" would only export the individuals in the group, an Individual Summary report of "everybody" would only list those individuals in the group, etc. The rest of the individuals in the database temporarily don't exist. Under these circumstances, the answer to Renee's question of "what if the duplicate is outside of the named group?" is answered by saying that the duplicate temporarily doesn't exist and is not listed by the Duplicate Search Merge process.

Just think of all the things that would work so much better. The Problem List could be restricted to a group. The Data Clean beta could be restricted to a group. RM Explorer searching and finding could be restricted to a group. Etc. It would be like you temporarily deleted everybody in your database except the group. And you could get everybody back basically with one click at the top of screen.

Not to get overly technical, but there is a conceptually simple way to implement this concept. There have to be a number of places in RM (of course I don't know how many) where RM performs SQL queries and updates against those tables which involve individuals. Such tables include the Person Table, the Name Table, the Event Table, etc. Replace each reference to these tables with an SQL subquery that selects only individuals in the current named group. Done. 99% of RM wouldn't even know that it's operating only on a group. Vyger's wish for Duplicate Search Merge would instantly be satisfied. But lots of other wishes would instantly be satisfied - for a more targeted DataClean, for a more targeted Problem Search, etc.

Jerry

#4 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 2315 posts

Posted 13 November 2013 - 07:10 PM

I don't want to hijack Vyger's thread, and my vision of how this would work might be different than his. But I will proceed anyway.


Firstly Jerry you are not hijacking my post but merely adding further justification to the underlying desires. A long time ago I recognized that one master database was the way forward as opposed to several smaller databases for specific research goals. The up side is one common Place List, one common Source List, standard sentencing templates etc., the downside is that Rootsmagic does yet not fully facilitate the working of subsets within such a database.

So I'm trying to picture this. You select to only work with a named group in duplicate merge search. But, what if the duplicate is outside of the named group? So I guess you want to search just a list of people and find any of their duplicates. Just wanted to clarify this before I add it in the tracking system.


Renee, firstly yes, any work within a Named Group would simply be restricted to that Named Group as it would be if it were a stand alone database. If the duplicate was outside of the particular Named Group then it would only be caught in a database wide DSM.

Really, as I believe Jerry was eluding to, it is a method of working with prescribed subsets of individuals as if they were part of smaller databases, using and defining these through Named Groups would seem to be the most logical way for users to define those subsets.

As I stated earlier having one complete master database is the logical way to go maintaining Place, Place Details, Source, Sentencing and other standards. However, IMO, Rootsmagic needs to better facilitate the effective working of specific subsets of information within the master database. In the case of Duplicate Search Merge restricting the scope to a Named Group to, for example, all surnames Sounding Like Doe and Any Place containing Texas is a big step up from comparing the worldwide Doe family.
Software Comparisons - Place Management - How other software packages stack up.
Media Gallery (a critical look) - Written when RM4 was introduced but still applies today.

Relaxation is the key to life and this is where I get some time to relax and catch up on my hobby and research s the key to life and this is where I get some time to catch up on me genealogy work and research

#5 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 3885 posts

Posted 14 November 2013 - 04:07 PM

Confirming enhancement request is in our tracking system.
Renee
RootsMagic





Also tagged with one or more of these keywords: dsm, merge, duplicates