I recently discovered that a large number of FindAGrave weblinks and citations have wound up under just a few individuals. This turned up in GEDCOM exports. How best move forward? There are probably 2000 errant weblinks. I think I can delete these using SQLite tools, but it looks pretty complex to reassociate those links with the right individual automatically. I think I am safer to reenter through the RM interface. Have I missed an easier path?
Now that I know it has happened I can find the extra weblinks through citation and weblink reports. NOTE: This is a self-inflicted wound. I don’t think RM did anything wrong, I think I blundered through some source and citation consolidations that I didn’t clearly understand.
FindAGrave links imported from Ancestry and FamilySearch have different source templates and I suspect I need to leave those in the system to keep TreeShare and the FS interchanges happy.
Ultimately I want a Source Template for Find A Grave and a separate source for every FindAGrave Memorial. Regardless of the access path(Ancestry, FamilySearch, Direct), each memorial is the underlying secondary source. Each one has separate authors, content, and quality. There would be multiple citations, but only the one weblink to the memorial. I suspect I will have the Ancestry and FamilySearch citations as “necessary” duplicates.
I haven’t gone down the Census sourcing rabbit hole yet, but suspect it may be similarly challenging as I have multiple paths to the same underlying films.
RM should have prevented you from hurting yourself. This is the direct result of a flawed feature: Merge all duplicate citations. I’m sure you can find prior discussions by searching on those terms.
The user definitely should have performed a backup …before invoking any program function that could affect multiples of database entries… potentially hurting themselves.
I have the backups, but don’t want to roll back that far! Since I wasn’t watching weblinks, it went unnoticed until I did a GEDCOM which showed the crosslinking. I suppose I could roll back RM9, and then use Ancestry to bring the tree info back up.
I use some GEDCOM data quality tools pretty regularly and I suspect I would have found it in those, but again, ignored the webtags as a future thing to explore.
You’re more ontop of things than most. Good for you! Another practice often not conducted by average users is to validate the outcome of any potential mass edit near in time to having done such.
Yes. My check didn’t go deep enough. Since then I have gotten into the SQLite browser habit to test the behavior more thoroughly. There weren’t webtags in my test DB, so I still may have butchered it up.
I have found that working in Wikitree and Using the GEDCOM tools has sharpened my knowledge of the RM behavior. I have artifacts from each of the previous generations of program in my sources, so that is some of the hardest stuff to clean up.
Based on Tom and Ken’s comments it occurred to me that as an active user of TreeShare I might be better served to download a new RM tree from Ancestry without the tangled citations.
Comparing the advanced DB Stats it looks like I will fix a lot of broken media links and the source/citation stuff at the cost of my geocoded place tables. I also have to figure out how to relink TreeShare.
The tools for places are pretty good, so that may be a decent tradeoff.
Agreed but the software should detect that citations having different WebTags or different Media are different citations, not duplicates. The feature is a trap that causes irreversible injury to the database for which the only recovery is to revert to a previous backup, which may undo much other valid work that has been done before or after the merge.
Remember when RM Inc would say that they would not provide bulk operations because users would get into trouble and Support would be overloaded? Now there are bulk features such as this nuclear one without even an “Are you sure?”, let alone a warning about the trap they’ve created - not even a word in the wiki!
This feature should not have been released as designed. This feature should have been corrected when its flaw was reported year(s) ago!
I obviously agree with almost all that You state, however, my emphasis in helping at this forum is to inform on problem-solving and potential best-practices. I, personally, do not use webtags. RootsMagic, Inc. has controlled many aspects with regards to mass-edit regret, but in response to this user-requested feature, they have definitely created another “gotcha”, (eg. unrelated but similarly needing further work is using the +Add Mother +Add Father greyed out hint block method versus the right-click context menu method of adding Parents).
As an advocate of modifying RM databases outside of the program’s own functionality, you’re well-aware and always recommend that a Backup be performed prior to any such operations, followed by a post-merge verification, so that one can immediately go back if anything is untoward (similar to checking that all the charges on your credit card are your own or reconciling ye oldentimes checkbook for missed entries/math errors).
Also, I just want to say that… a user does not necessarily have to revert (losing all changes). Instead, restoring that backup to a different location and having access to a resource for rescue/recovery/repair via dragNdrop/GED or the dreaded manual re-typing repair can be used to mitigate potentially massive setbacks.
