What if it isn’t a typo? People go in occasionally to FAG and add a duplicate memorial, when it is discovered one of them is removed, it could be the one that you are citing. I have had it happened to me occasionally. Annoying, but ok for me because I am putting the number in the description section of events under cemetery. I can see where it would really mess up individuals that have used the FAG field in v9. Don’t know of a solution for it. The program should say which individual they are removing the number so you can go back and put in the new number.
Donna Newell Ardmore, Oklahoma Sent from my iPad > On Oct 12, 2017, at 4:43 AM, Henry T. Peterson Jr. <hpete...@cox.net> wrote: > > Ian > > My two cents…. I have over 13,000 FAG memorials in my database and most of > the time they are entered by copy and paste (I use two monitors while > entering data). I for one am grateful that “File maintenance – check/repair” > catches these errors.. otherwise they would go undetected and be a totally > unfunctional. > > It not “Legacy’s” fault I made the typo errors. I don’t know a solution, but > I would hate to lose the basic functionality that check/repair provides. > > My two cents > Kind regards > Henry > > > From: LegacyUserGroup [mailto:legacyusergroup-boun...@legacyusers.com] On > Behalf Of Ian Macaulay > Sent: Wednesday, October 11, 2017 11:15 PM > To: Legacy User Group <LegacyUserGroup@legacyusers.com> > Subject: [LegacyUG] a Warning, and another problem with the FAG > > I would very much like the FAG numbers to be unique, however the current > situation where if you have a duplicate number and run "File Maintenance" you > get a message that says > > Duplicate Find a Grave IDs have been found. You will need to re-add the Find > a Grave ID back to the individual the ID belongs to. You can search Find a > Grave using the ID(s) listed below for who it should be added to. > ====================================================================== > > Find A Grave ID = 77730037 > > And it wipes out both the good and the bad numbers., Now while the good is > easy to recover because they capture it and report , the bad is lost. So > in effect Legacy programmers have programed a scenario that looses a clients > data. > > -- > ICMac Sales: Hobby consultant (1986r.) > Office hours: 10:00 Am - 5:00 PM most days > Macaulay Genealogy > Family Matters > Ian Macaulay of Carp, Ontario > -- > > LegacyUserGroup mailing list > LegacyUserGroup@legacyusers.com > To manage your subscription and unsubscribe > http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com > Archives at: > http://www.mail-archive.com/legacyusergroup@legacyusers.com/
-- LegacyUserGroup mailing list LegacyUserGroup@legacyusers.com To manage your subscription and unsubscribe http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com Archives at: http://www.mail-archive.com/legacyusergroup@legacyusers.com/
