Loading ...
Sorry, an error occurred while loading the content.

Re: [AQ_NFS] Check for Changes

Expand Messages
  • Bob Penry
    I recently had to use the unlink feature. Why. Because so many records in NFS have been combined wrong (father/son) combined together, cousins with same
    Message 1 of 31 , Aug 30, 2011
    View Source
    • 0 Attachment
      I recently had to use the unlink feature. Why. Because so many records in NFS have been combined wrong (father/son) combined together, cousins with same name, men with same names and wives also have same names - You get the picture.

      What happened was that I had some individuals in my file that when I linked them to NFS, There were two different individuals with the same NFS-ID because of bad combos. There were 38 total individuals, 19 sets of duplicate NFS-ID's. I went into NFS and uncombined to make NFS correct (some had over 100 combos to sort out). After I was finished, only 19 individuals had the correct NFS-ID. I then unlinked the other 19 and did an upload to get the information and new NFS-ID

      NOTE: VERY IMPORTANT. Because of the bad combos, there were three of the individuals that showed all ordinance work completed before the uncombine and afterwards needed work. This shows how very, very crucial it is to make sure that work has really been done and that it is not a result of bad combos.



      ----- Original Message -----
      From: Gaylon Findlay
      To: AQ_NFS@yahoogroups.com
      Sent: Monday, August 29, 2011 4:42 PM
      Subject: Re: [AQ_NFS] Check for Changes



      Don:

      This sounds right to me. :-)

      Although I can't see any reason to unlink a person just for the sake of
      unlinking him. Other than for a couple of situations.

      1) Let's say that you have linked two parents in your file to their
      corresponding records in NFS. Later you decide to add (upload) a child
      from your database to NFS. After AQ addes the child to NFS, it uses the
      links of the parents in your database to make sure it connects the child
      to the parents in nFS. If you, for some reason, did not want the child
      added to the family of the parents in NFS, you would have to first
      unlink the parents, so that AQ would not automatically connect the newly
      uploaded child to the NFS family.

      2) After using NFS for a while, someone may not want to work with nFS
      anymore. I think this is less likely for LDS users, and more likely for
      non-LDS users. I can see where someone would be more comfortable
      unlinking individuals to feel like they've made a clean break from nFS.

      3) You have a database with which you train others. Sometimes it is
      advantageous to unlink everyone before the start of a new class, so you
      can go through the process of teaching students how to link records to NFS.

      Gaylon

      On 8/28/2011 1:00 AM, Donald R. Snow wrote:
      > So, Gaylon, if we copy a person's NFS PID to somewhere else, e.g. his
      > notes or an event for him, and then unlink them, we can still keep track
      > of the PID, even though the person is unlinked, since the PID is not in
      > a location where AQ expects to find it. Is that right? I can see how
      > that might be helpful in certain cases.
      >
      > Don
      >
      >
      > On 2011-08-26 3:42 PM, Gaylon Findlay wrote:
      >> Leslie:
      >>
      >> We struggled to find the right terms for describing linking and syncing.
      >> As a result, some of the terminology in AQ may not seem consistent, as
      >> it evolved over time. I'll try to explain below with the best
      >> terminology that we have come up with, which may or may not match what
      >> you are seeing on some screens.
      >>
      >> When you link a person to NFS, this means that AQ records the NFS PID
      >> into the local PAF or AQ record. Thus, AQ now knows which record in the
      >> NFS system matches your local record.
      >>
      >> When you unlink a person from NFS, AQ removes that NFS PID from the
      >> local PAF or AQ record. Thus, AQ has forgotten which record in the NFS
      >> system matches your local record.
      >>
      >> If AQ can show you the NFS PID for a person, that means that the person
      >> is linked to NFS. If AQ cannot show this ID, then the person is not
      >> linked to NFS.
      >>
      >> Syncing is a different issue. AQ does not attempt to fully synchronize
      >> your local record with a record in NFS. Once you have linked your record
      >> to NFS, then you can selectively exchange items of data between your
      >> records and NFS. We call this "Syncing" or "Selective Syncing." Even
      >> after you unlink your record from NFS, the items you have exchanged
      >> during such a selective sync will remain.
      >>
      >> Maybe another way of explaining this is that "being linked" is a status.
      >> "Linking" or "Unlinking" are verbs that describe changing that status.
      >> "Syncing" is a verb that describes a one-time action of exchanging data
      >> between your local file and NFS. Because AQ never attempts to fully
      >> synchronize records, this should always be thought of as "Selective
      >> Syncing."
      >>
      >> Gaylon
      >>
      >> On 8/25/2011 6:52 PM, Leslie Vaughn wrote:
      >>> I have done what you have suggested which takes more key strokes
      >> than the view of changes, which I would like to see.
      >>> But I guess this brings my underlying question. What does AQ mean
      >> when it says that it is not synced? Is it just the absence of the PID
      >> that makes the system say it is not synched? I know that if there is
      >> no PID that the individual is very likely not synched, but what if
      >> there is a PID? Does AQ automatically report that if there is a PID
      >> that it is synched, and conversely that if there is no PID that it is
      >> not synched? What happens if I have synched and then later unlinked
      >> from nfs. but forget to take out the PID? Or if the PID is removed
      >> without unlinking from nfs?
      >>>
      >>>
      >>> Leslie
      >>>
      >>>
      >>> From: Margaret Thompson
      >>> Sent: Thursday, August 25, 2011 8:37 PM
      >>> To: AQ_NFS@yahoogroups.com<mailto:AQ_NFS%40yahoogroups.com>
      >>> Subject: Re: [AQ_NFS] Check for Changes
      >>>
      >>>
      >>>
      >>> To get a list of those not synced to nFS go to Search->Advanced
      >>> Filter/Focus->Advanced->Select by Relationships->Field
      >>> Selections->Define->choose FS PID->does not exist
      >>>
      >>> This will give you a list of those in your file who are not linked
      >> to nFS
      >>> (don't have a FS PID).
      >>>
      >>> Margaret
      >>>
      >>> -----Original Message-----
      >>> From: Leslie Vaughn
      >>> Sent: Thursday, August 25, 2011 4:06 PM
      >>> To: AQ_NFS@yahoogroups.com<mailto:AQ_NFS%40yahoogroups.com>
      >>> Subject: Re: [AQ_NFS] Check for Changes
      >>>
      >>> When I select a group of names to check for changes, such as a family or
      >>> using any filter to create a list, I can run the check for changes
      >> feature
      >>> and get a list showing the number that have changed, the number that
      >> have
      >>> not changed and the number that are not synched to NFS.
      >>>
      >>> I can view those individuals who show changes.
      >>>
      >>> Is there any way to get a list of those not synched to NFS?
      >>>
      >>> I don't want an all inclusive list of EVERYONE in my data base not in
      >>> synched. I would just like to work with a few at a time. It would be
      >> great
      >>> to view them similar to the view button allowing me to review those
      >> who do
      >>> show changes.
      >>>
      >>> I know that I can create a list using the criteria that I chose and
      >> the I
      >>> can select to show results only and then scroll through them to see
      >> if there
      >>> is a missing PID but that is cumbersome and probably not accurate. There
      >>> have been times when I have unlinked someone from nfs and forgotten to
      >>> remove the PID
      >>>
      >>> Thank you
      >>>
      >>> Leslie Vaughn
      >>>
      >>> [Non-text portions of this message have been removed]
      >>>
      >>> ------------------------------------
      >>>
      >>> Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>>
      >>>
      >>> [Non-text portions of this message have been removed]
      >>>
      >>>
      >>>
      >>> ------------------------------------
      >>>
      >>> Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>>
      >>




      [Non-text portions of this message have been removed]
    • Gaylon Findlay
      Niel: FamilySearch attaches a marker to each record. Anytime a change is made to that record, the marker is also changed, so that programs such as Family Tree,
      Message 31 of 31 , Jul 6, 2013
      View Source
      • 0 Attachment
        Niel:

        FamilySearch attaches a marker to each record. Anytime a change is made to that record, the marker is also changed, so that programs such as Family Tree, AQ and others can be alerted that a change has been made.

        When you initially link one of your records in your personal file to its corresponding record in Family Tree, AQ records this marker. When you run "Check for Changes," AQ compares the markers it has recorded with the current markers in Family Tree. If the markers are the same, then AQ knows that no changes were made to the Family Tree record since you last looked at the record. If the markers are different, then AQ knows that some change has been made to the Family Tree record, and it puts this record on a list for you to review. AQ doesn't know specifically what has changed -- only that FamilySearch reports that something has changed.

        Unfortunately, when FamilySearch moved records from nFS to FamilyTree, they created new markers for every record in their system. So the first time you run Check for Changes after switching from an older version of AQ (which looked at the old markers of nFS) to a newer version (which now looks at the markers of Family Tree), every record will be listed as having changed. Because of this, we added a "Mark All" button to the Check for Changes review screen, which allows you to quickly update the markers of every linked record in your AQ file with new markers from Family Tree. If you use this option, you may miss reviewing some legitimate changes to some of the records you are working with, but you will be set up so that in the future, Check for Changes will only show you records that have actually changed since you marked them.

        Hope this helps.

        Gaylon


        ----- Original Message -----
        From: "Neil Hallam" <hallamnr@...>
        To: "AQ NFS" <AQ_NFS@yahoogroups.com>
        Sent: Saturday, July 6, 2013 5:13:17 AM
        Subject: [AQ_NFS] Check for Changes

        Could someone please explain what the "Check for changes" (under Family
        Search) function is designed for. When I use it I get a great list of names
        bur I am unable to see what changes have occurred. I'm sure it must serve
        some useful purpose.
        Neil R Hallam
        hallamnr@...


        [Non-text portions of this message have been removed]



        ------------------------------------

        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.