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

Re: [AQ_NFS] False positives using "Check for changes" option

Expand Messages
  • Leslievaughn@cfl.rr.com
    Thanks for the info, Gaylon. I knew that any little change could cause the changes to show when I did check for changes, but I wasn t aware that I might need
    Message 1 of 22 , Jun 10, 2010
      Thanks for the info, Gaylon.

      I knew that any little change could cause the changes to show when I did check for changes, but I wasn't aware that I might need to check/Repair. I was getting some false positives on about 17 names.

      Each time a change had really occurred on nFS and I reviewed it, that name would always show up in my changed list.

      I just did check/repair and checked for changes. I got 38 matches. I reviewed them all and checked for changes again and then I only got one. I keep getting that 1 even though I ran the check/repair again. But 1 is certainly better than the others.

      Leslie Vaughn



      ---- Gaylon Findlay <gfindlay@...> wrote:
      > Bob:
      >
      > When you initially link a local record with the NFS record, AQ records a
      > version number from the NFS record. Later, if you review the record in
      > AQ and hit the "Save" button, AQ will update the recorded version number
      > from NFS for that record.
      >
      > When you use the "Check for Changes" option from AQ's FamilySearch menu,
      > AQ will compare the version number it recorded earlier from NFS with the
      > current version number of the NFS record. If the number has not changed,
      > that means that nothing has changed in the NFS record since the last
      > time you looked at it via AQ. If the version number for the NFS record
      > has changed, then AQ lets you know that something has changed in that
      > record.
      >
      > The change could be almost anything. For example, the record has been
      > combined with another NFS record, or someone entered a note or a source,
      > or someone disputed something. Without making a complete local copy of
      > all the data in the NFS record (which would use up all your hard disk
      > space), AQ is unable to tell you what has changed -- it simply relies on
      > the version number to learn that *something* has changed.
      >
      > If AQ were to somehow lose the version numbers due to some corruption in
      > the database, you could end up with "false positives" -- where AQ cannot
      > accurately compare an old version number with the current version number
      > for an NFS record. If you've run the Database Check/Repair and found no
      > problems, then this should not be a problem. If Check/Repair finds
      > problems in the NFS portion of the AQ or PAF file, it may indicate that
      > some of these version numbers were lost, which would cause AQ to report
      > that a change has been made, when it might possibly not have changed.
      >
      > Gaylon
      >
      >
      > ChinaBob wrote:
      > > Gaylon,
      > > I seem to be getting a fair amount of false positives when using the NFS "Check for changes" option.
      > >
      > > By false positives, i mean that the program says there has been updates to the NFS information but on reviewing the information in detail, no differences can be found.
      > >
      > > Is the check for differences something that AQ does or is the check performed by NSF?
      > >
      > > One item that always seems to show up as a difference is when there is something in the local sealing data but the NFS data is blank.
      > >
      > > This is a great tool for keeping my local database sync'd up with research and temple work being done by other groups on my same lines. Any help or suggestions would be greatly appreciated.
      > >
      > > Thanks, Bob.
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
    • Scott, Robert L
      Gaylon, Thank you for the information - understanding what is going on behind the scenes always helps. I ve taken a day or so to really try to understand what
      Message 2 of 22 , Jun 11, 2010
        Gaylon,
        Thank you for the information - understanding what is going on behind the scenes always helps.

        I've taken a day or so to really try to understand what the process is and how it impacts us. Please correct me if I have this wrong.

        First, there is not function that truly compares what I have locally against what is found in NFS. What we have now is good in that it is fast and mostly accurate. But it seems to me that a function that would compare my data against what NFS has - even if it needs to run overnight or in the background - would be a good addition (for the reasons I list below).


        * If I review a record, find no changes, and exit without "saving" anything, what happens to the revision number? Will this record continue to show up?


        * Next, if I review a record with some changes, accept some of the changes (ie. temple work) but do not accept other changes (ie. birth/death dates or information on spouse/parents windows) and SAVE those changes, that this record will NOT show up the next time, even though there are still differences.


        * Or if I make changes to my local database updating any of the information in an individual's record (and didn't update NFS at that time), nothing will highlight that my local record is different/updated.

        BTW, a couple of very useful additions to this screen: enable ctrl-E as a keyboard shortcut (instead of only having the review button), allow the editing of the local record (without having to get out of the screen), and make the notation that something has changed in NFS persistent (ie. part of the individual's record) and displayable on the name list screen.

        Lastly, the problem with the corrupted files may be part of the problem. I get corrupted files on a regular basis and each time I will get 200-300 NFS record problems. No one has been able to tell me what the impact of that corruption was (until now). What I understood is that if the NFS information is lost on a record, then the version number reverts back to 0 and that record will show up next time I request a list of changes. Is that the only information that is lost with a corrupted NFS record?

        Thanks, Bob.

        From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of Gaylon Findlay
        Sent: Thursday, June 10, 2010 10:21 AM
        To: AQ_NFS@yahoogroups.com
        Subject: Re: [AQ_NFS] False positives using "Check for changes" option



        Bob:

        When you initially link a local record with the NFS record, AQ records a
        version number from the NFS record. Later, if you review the record in
        AQ and hit the "Save" button, AQ will update the recorded version number
        from NFS for that record.

        When you use the "Check for Changes" option from AQ's FamilySearch menu,
        AQ will compare the version number it recorded earlier from NFS with the
        current version number of the NFS record. If the number has not changed,
        that means that nothing has changed in the NFS record since the last
        time you looked at it via AQ. If the version number for the NFS record
        has changed, then AQ lets you know that something has changed in that
        record.

        The change could be almost anything. For example, the record has been
        combined with another NFS record, or someone entered a note or a source,
        or someone disputed something. Without making a complete local copy of
        all the data in the NFS record (which would use up all your hard disk
        space), AQ is unable to tell you what has changed -- it simply relies on
        the version number to learn that *something* has changed.

        If AQ were to somehow lose the version numbers due to some corruption in
        the database, you could end up with "false positives" -- where AQ cannot
        accurately compare an old version number with the current version number
        for an NFS record. If you've run the Database Check/Repair and found no
        problems, then this should not be a problem. If Check/Repair finds
        problems in the NFS portion of the AQ or PAF file, it may indicate that
        some of these version numbers were lost, which would cause AQ to report
        that a change has been made, when it might possibly not have changed.

        Gaylon

        ChinaBob wrote:
        > Gaylon,
        > I seem to be getting a fair amount of false positives when using the NFS "Check for changes" option.
        >
        > By false positives, i mean that the program says there has been updates to the NFS information but on reviewing the information in detail, no differences can be found.
        >
        > Is the check for differences something that AQ does or is the check performed by NSF?
        >
        > One item that always seems to show up as a difference is when there is something in the local sealing data but the NFS data is blank.
        >
        > This is a great tool for keeping my local database sync'd up with research and temple work being done by other groups on my same lines. Any help or suggestions would be greatly appreciated.
        >
        > Thanks, Bob.
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >



        [Non-text portions of this message have been removed]
      • Ken Doyle
        Dear Robert, I found another thing that caused me to get about 5000 changes was I decidedafter linking to nFS. This was to standardise the place names in my
        Message 3 of 22 , Jun 11, 2010
          Dear Robert,

          I found another thing that caused me to get about 5000 changes was I decidedafter linking to nFS. This was to standardise the place names in my database.

          http://labs.familysearch.org/

          http://204.9.231.95/stdfinder/PlaceStandardLookup.jsp

          I used lds labs Standard Finder and then globally changed many many records a smidgen in my local database.

          This was one of the major reasons I have 4961 changed records out of 5881 records that are linked to nFS that were compared.

          Now I have about about 59,000 names left to link to new FamilySearch. I also have about another 12,500 names to enter, manually, into my database too and then link to nFS. These are mainly in a couple of other databases.

          I am adopted and have split my research into adopted, original mother and original father databases. Currently I am linking my adopted genealogy. I give my adopted genealogy first priority. So I am learning by my mistakes on this genealogy before I go onto my original genealogies. I still have many thousands of names to enter in my adopted genealogy yet.

          So this has taught me a BIG LESSON. Do all the changes to you own records first as far as getting place names right etc. Then link to new FamilySearch. Can you imagine how depressing it was to see I had 4961 records to go through. (Still need to go through).

          I think this is worth remembering to get our data right as far as global changes such as using Standard Finder. Then link to new Family Search. Working that way saves many hours (months).

          It is a pity I cannot globally make changes to nFS on place names.

          ===============================================================================================

          At work we produce detail structural drawings for steelwork for mines, port facilities, schools, universities, shopping centres etc. It is very common to produce thousands of drawings. On a recent small hospital we produced about 11,000 drawings.

          We have learnt the order in which we check the drawings is very important. If we find a mistake we then go into the 3D CAD model and fix it so the drawing is fixed. Now if you check the wrong way round you end up doing things four times.

          So we have learnt by trial and error it is best to proceed in a set sequence that minimises time.

          ================================================================================================

          In a similar manner I am just beginning to realise similar principles apply with new Family Search and our local databases.

          We need to do global changes to our databases first and then link to new FamilySearch.

          Has anyone else discovered there needs to be things done in a certain order to minimise work?
           
           
          Cheers,

          Ken Doyle

          Phone:  02 63 61 8865  02 63 61 8865
          International Phone: 612 63 61 8865





          ________________________________
          From: "Scott, Robert L" <robert.l.scott@...>
          To: "AQ_NFS@yahoogroups.com" <AQ_NFS@yahoogroups.com>
          Sent: Sat, 12 June, 2010 2:13:01 AM
          Subject: RE: [AQ_NFS] False positives using "Check for changes" option

           
          Gaylon,
          Thank you for the information - understanding what is going on behind the scenes always helps.

          I've taken a day or so to really try to understand what the process is and how it impacts us. Please correct me if I have this wrong.

          First, there is not function that truly compares what I have locally against what is found in NFS. What we have now is good in that it is fast and mostly accurate. But it seems to me that a function that would compare my data against what NFS has - even if it needs to run overnight or in the background - would be a good addition (for the reasons I list below).

          * If I review a record, find no changes, and exit without "saving" anything, what happens to the revision number? Will this record continue to show up?

          * Next, if I review a record with some changes, accept some of the changes (ie. temple work) but do not accept other changes (ie. birth/death dates or information on spouse/parents windows) and SAVE those changes, that this record will NOT show up the next time, even though there are still differences.

          * Or if I make changes to my local database updating any of the information in an individual's record (and didn't update NFS at that time), nothing will highlight that my local record is different/updated.

          BTW, a couple of very useful additions to this screen: enable ctrl-E as a keyboard shortcut (instead of only having the review button), allow the editing of the local record (without having to get out of the screen), and make the notation that something has changed in NFS persistent (ie. part of the individual's record) and displayable on the name list screen.

          Lastly, the problem with the corrupted files may be part of the problem. I get corrupted files on a regular basis and each time I will get 200-300 NFS record problems. No one has been able to tell me what the impact of that corruption was (until now). What I understood is that if the NFS information is lost on a record, then the version number reverts back to 0 and that record will show up next time I request a list of changes. Is that the only information that is lost with a corrupted NFS record?

          Thanks, Bob.

          From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of Gaylon Findlay
          Sent: Thursday, June 10, 2010 10:21 AM
          To: AQ_NFS@yahoogroups.com
          Subject: Re: [AQ_NFS] False positives using "Check for changes" option

          Bob:

          When you initially link a local record with the NFS record, AQ records a
          version number from the NFS record. Later, if you review the record in
          AQ and hit the "Save" button, AQ will update the recorded version number
          from NFS for that record.

          When you use the "Check for Changes" option from AQ's FamilySearch menu,
          AQ will compare the version number it recorded earlier from NFS with the
          current version number of the NFS record. If the number has not changed,
          that means that nothing has changed in the NFS record since the last
          time you looked at it via AQ. If the version number for the NFS record
          has changed, then AQ lets you know that something has changed in that
          record.

          The change could be almost anything. For example, the record has been
          combined with another NFS record, or someone entered a note or a source,
          or someone disputed something. Without making a complete local copy of
          all the data in the NFS record (which would use up all your hard disk
          space), AQ is unable to tell you what has changed -- it simply relies on
          the version number to learn that *something* has changed.

          If AQ were to somehow lose the version numbers due to some corruption in
          the database, you could end up with "false positives" -- where AQ cannot
          accurately compare an old version number with the current version number
          for an NFS record. If you've run the Database Check/Repair and found no
          problems, then this should not be a problem. If Check/Repair finds
          problems in the NFS portion of the AQ or PAF file, it may indicate that
          some of these version numbers were lost, which would cause AQ to report
          that a change has been made, when it might possibly not have changed.

          Gaylon

          ChinaBob wrote:
          > Gaylon,
          > I seem to be getting a fair amount of false positives when using the NFS "Check for changes" option.
          >
          > By false positives, i mean that the program says there has been updates to the NFS information but on reviewing the information in detail, no differences can be found.
          >
          > Is the check for differences something that AQ does or is the check performed by NSF?
          >
          > One item that always seems to show up as a difference is when there is something in the local sealing data but the NFS data is blank.
          >
          > This is a great tool for keeping my local database sync'd up with research and temple work being done by other groups on my same lines. Any help or suggestions would be greatly appreciated.
          >
          > Thanks, Bob.
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >

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







          [Non-text portions of this message have been removed]
        • Mary-Theresa Dameron
          I m glad for the links on this email, that is one of my main problems, standardizing place names - it nearly drives me crazy. Mary-Theresa Dameron [Non-text
          Message 4 of 22 , Jun 11, 2010
            I'm glad for the links on this email, that is one of my main problems,
            standardizing place names - it nearly drives me crazy.



            Mary-Theresa Dameron







            [Non-text portions of this message have been removed]
          • Gaylon Findlay
            ... What you probably have in your file is only the information you consider of value. On NFS, there is (hopefully) that useful information, along with often a
            Message 5 of 22 , Jun 11, 2010
              > First, there is not function that truly compares what I have locally against what is found in NFS. What we have now is good in that it is fast and mostly accurate. But it seems to me that a function that would compare my data against what NFS has - even if it needs to run overnight or in the background - would be a good addition (for the reasons I list below).
              >
              What you probably have in your file is only the information you consider
              of value. On NFS, there is (hopefully) that useful information, along
              with often a lot of information that is not so useful. Unless you bring
              all of the less useful information into your file, AQ would almost
              always find differences between what you have and what is in NFS. In
              order for a review process to be useful, AQ would need to record exactly
              what was contained in both your record and in the NFS record the last
              time you compared them, so that it could compare both your current
              record and the current NFS record against the old records when you run
              this function. This would be extremely useful, as it would tell you
              exactly what had changed in either record, but this would also tend to
              eat up more room on your hard disk than most users would be willing to
              allow for genealogy record keeping. And there is another problem. Until
              the "February/March" release of NFS, AQ could download everything it
              might need to store for a typical record in about 8 seconds. After the
              "February/March" release of NFS, to get the same information from NFS
              would now take about 4-5 minutes. That's just for one relatively simple
              NFS record. (Complex NFS records would take much, much longer.) To
              record everything of value from NFS, for purposes of a later comparison
              review, now simply takes too long to be feasible. (Prior to the
              Feb/March release of NFS, AQ used to always read all the information
              from NFS so it would be ready for you. After the Feb/March release of
              NFS, AQ now reads everything but the notes and sources from NFS, and
              waits for you to ask for notes and sources before it retrieves them.
              Unless you take the time to look through all the notes and all the
              sources for an NFS record, you'll end up never retrieving the *entire*
              information on an NFS record with the newer builds of AQ.)
              >
              > * If I review a record, find no changes, and exit without "saving" anything, what happens to the revision number? Will this record continue to show up?
              >
              This depends, I believe, on whether you are reviewing from the "Check
              for Changes" screen, or from the Pedigree or Family view. I believe that
              if you review the record from the Check for Changes screen, the version
              number will be updated so that the next time you use the Check for
              Changes feature, it will not show up, unless another change has been
              made. However, if you review from the Pedigree or Family view, if you
              Close rather than Save, the version number will not be updated, so the
              next time you run the Check for Changes, the process will check against
              an older version number. You don't have to actually save anything --
              just use the "Save" button rather than the "Close" button to close this
              screen.
              >
              > * Next, if I review a record with some changes, accept some of the changes (ie. temple work) but do not accept other changes (ie. birth/death dates or information on spouse/parents windows) and SAVE those changes, that this record will NOT show up the next time, even though there are still differences.
              >
              Correct. Whether you accept any data from NFS at all, simply using the
              Save button to close this screen will indicate to AQ that you have
              reviewed it, and don't want to be reminded to look at it again until
              another change is made.
              >
              > * Or if I make changes to my local database updating any of the information in an individual's record (and didn't update NFS at that time), nothing will highlight that my local record is different/updated.
              >
              The Check for Changes feature only checks for changes on the NFS
              records, not for changes to your local records. To check for changes on
              your local records, use the "Change Log" feature in AQ. (This is found
              under the "Tools" menu. If you are using an AQ database, it keeps a very
              detailed log of your changes, but if you are using a PAF database, the
              log of changes is much more cryptic.)
              > Lastly, the problem with the corrupted files may be part of the problem. I get corrupted files on a regular basis and each time I will get 200-300 NFS record problems. No one has been able to tell me what the impact of that corruption was (until now). What I understood is that if the NFS information is lost on a record, then the version number reverts back to 0 and that record will show up next time I request a list of changes. Is that the only information that is lost with a corrupted NFS record?
              >
              I think that sometimes when you get errors in the NFS portion of your
              file, some of the version numbers could be lost, and sometimes this may
              even cause the linkages between local records and NFS records to be lost
              -- meaning you'd have to link the records again. But most of the time, I
              think that there are no bad side-effects to having these NFS records
              reported in the Check/Repair process. In these cases, it is a matter of
              "house-cleaning" -- when AQ went to rewrite some NFS information, it
              wrote the new information and forgot to properly remove old data. In
              this case, the Check/Repair often simply completes the process of
              cleaning out old data that should have been removed earlier. If anyone
              finds a sequence of steps that causes these errors/warnings to show up
              in Check/Repair, we are very anxious hear of this so we can fix AQ to
              never again allow the NFS portion of the file to show problems in
              Check/Repair :-)

              Gaylon
            • Scott, Robert L
              Gaylon, Okay, one more question and then I will give this a rest :) There seems to be one piece missing here. You indicated that this Check for Changes
              Message 6 of 22 , Jun 11, 2010
                Gaylon,
                Okay, one more question and then I will give this a rest :)

                There seems to be one piece missing here. You indicated that this "Check for Changes" process only checks for changes in NFS. If so, why would changes to the locations in the local database (see Ken Doyle's email) show up as differences with NFS?

                Thanks a bunch for your help. Bob.


                From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of Gaylon Findlay
                Sent: Friday, June 11, 2010 3:26 PM
                To: AQ_NFS@yahoogroups.com
                Subject: Re: [AQ_NFS] False positives using "Check for changes" option



                > First, there is not function that truly compares what I have locally against what is found in NFS. What we have now is good in that it is fast and mostly accurate. But it seems to me that a function that would compare my data against what NFS has - even if it needs to run overnight or in the background - would be a good addition (for the reasons I list below).
                >
                What you probably have in your file is only the information you consider
                of value. On NFS, there is (hopefully) that useful information, along
                with often a lot of information that is not so useful. Unless you bring
                all of the less useful information into your file, AQ would almost
                always find differences between what you have and what is in NFS. In
                order for a review process to be useful, AQ would need to record exactly
                what was contained in both your record and in the NFS record the last
                time you compared them, so that it could compare both your current
                record and the current NFS record against the old records when you run
                this function. This would be extremely useful, as it would tell you
                exactly what had changed in either record, but this would also tend to
                eat up more room on your hard disk than most users would be willing to
                allow for genealogy record keeping. And there is another problem. Until
                the "February/March" release of NFS, AQ could download everything it
                might need to store for a typical record in about 8 seconds. After the
                "February/March" release of NFS, to get the same information from NFS
                would now take about 4-5 minutes. That's just for one relatively simple
                NFS record. (Complex NFS records would take much, much longer.) To
                record everything of value from NFS, for purposes of a later comparison
                review, now simply takes too long to be feasible. (Prior to the
                Feb/March release of NFS, AQ used to always read all the information
                from NFS so it would be ready for you. After the Feb/March release of
                NFS, AQ now reads everything but the notes and sources from NFS, and
                waits for you to ask for notes and sources before it retrieves them.
                Unless you take the time to look through all the notes and all the
                sources for an NFS record, you'll end up never retrieving the *entire*
                information on an NFS record with the newer builds of AQ.)
                >
                > * If I review a record, find no changes, and exit without "saving" anything, what happens to the revision number? Will this record continue to show up?
                >
                This depends, I believe, on whether you are reviewing from the "Check
                for Changes" screen, or from the Pedigree or Family view. I believe that
                if you review the record from the Check for Changes screen, the version
                number will be updated so that the next time you use the Check for
                Changes feature, it will not show up, unless another change has been
                made. However, if you review from the Pedigree or Family view, if you
                Close rather than Save, the version number will not be updated, so the
                next time you run the Check for Changes, the process will check against
                an older version number. You don't have to actually save anything --
                just use the "Save" button rather than the "Close" button to close this
                screen.
                >
                > * Next, if I review a record with some changes, accept some of the changes (ie. temple work) but do not accept other changes (ie. birth/death dates or information on spouse/parents windows) and SAVE those changes, that this record will NOT show up the next time, even though there are still differences.
                >
                Correct. Whether you accept any data from NFS at all, simply using the
                Save button to close this screen will indicate to AQ that you have
                reviewed it, and don't want to be reminded to look at it again until
                another change is made.
                >
                > * Or if I make changes to my local database updating any of the information in an individual's record (and didn't update NFS at that time), nothing will highlight that my local record is different/updated.
                >
                The Check for Changes feature only checks for changes on the NFS
                records, not for changes to your local records. To check for changes on
                your local records, use the "Change Log" feature in AQ. (This is found
                under the "Tools" menu. If you are using an AQ database, it keeps a very
                detailed log of your changes, but if you are using a PAF database, the
                log of changes is much more cryptic.)
                > Lastly, the problem with the corrupted files may be part of the problem. I get corrupted files on a regular basis and each time I will get 200-300 NFS record problems. No one has been able to tell me what the impact of that corruption was (until now). What I understood is that if the NFS information is lost on a record, then the version number reverts back to 0 and that record will show up next time I request a list of changes. Is that the only information that is lost with a corrupted NFS record?
                >
                I think that sometimes when you get errors in the NFS portion of your
                file, some of the version numbers could be lost, and sometimes this may
                even cause the linkages between local records and NFS records to be lost
                -- meaning you'd have to link the records again. But most of the time, I
                think that there are no bad side-effects to having these NFS records
                reported in the Check/Repair process. In these cases, it is a matter of
                "house-cleaning" -- when AQ went to rewrite some NFS information, it
                wrote the new information and forgot to properly remove old data. In
                this case, the Check/Repair often simply completes the process of
                cleaning out old data that should have been removed earlier. If anyone
                finds a sequence of steps that causes these errors/warnings to show up
                in Check/Repair, we are very anxious hear of this so we can fix AQ to
                never again allow the NFS portion of the file to show problems in
                Check/Repair :-)

                Gaylon



                [Non-text portions of this message have been removed]
              • Gaylon Findlay
                Bob: I just re-read part of Ken s message. If I understand it correctly (and I may have misunderstood something he said), he had made lots of changes to his
                Message 7 of 22 , Jun 11, 2010
                  Bob:

                  I just re-read part of Ken's message. If I understand it correctly (and
                  I may have misunderstood something he said), he had made lots of changes
                  to his file by way of adjusting many place names. Knowing the code as I
                  do, I don't believe that this would have any affect on the Check for
                  Changes -- at least not if AQ were the tool you used to adjust the place
                  names.

                  Ken mentions a tool he used to help in this project. Some tools could
                  actually cause the linkages to NFS to be lost. For example, if you use
                  FamilyInsight to adjust place names, you should be fine. But if you use
                  the older PAF Insight to adjust place names in a PAF database, PAF
                  Insight would throw away all the links to NFS. Make sure the tools you
                  use are certified properly with both NFS and with your local database.
                  (Certification doesn't actually mean much -- make sure you test the tool
                  to see that it does what you hope it will do.)

                  Gaylon


                  Scott, Robert L wrote:
                  > Gaylon,
                  > Okay, one more question and then I will give this a rest :)
                  >
                  > There seems to be one piece missing here. You indicated that this "Check for Changes" process only checks for changes in NFS. If so, why would changes to the locations in the local database (see Ken Doyle's email) show up as differences with NFS?
                  >
                  > Thanks a bunch for your help. Bob.
                  >
                  >
                  > From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of Gaylon Findlay
                  > Sent: Friday, June 11, 2010 3:26 PM
                  > To: AQ_NFS@yahoogroups.com
                  > Subject: Re: [AQ_NFS] False positives using "Check for changes" option
                  >
                  >
                  >
                  >
                  >> First, there is not function that truly compares what I have locally against what is found in NFS. What we have now is good in that it is fast and mostly accurate. But it seems to me that a function that would compare my data against what NFS has - even if it needs to run overnight or in the background - would be a good addition (for the reasons I list below).
                  >>
                  >>
                  > What you probably have in your file is only the information you consider
                  > of value. On NFS, there is (hopefully) that useful information, along
                  > with often a lot of information that is not so useful. Unless you bring
                  > all of the less useful information into your file, AQ would almost
                  > always find differences between what you have and what is in NFS. In
                  > order for a review process to be useful, AQ would need to record exactly
                  > what was contained in both your record and in the NFS record the last
                  > time you compared them, so that it could compare both your current
                  > record and the current NFS record against the old records when you run
                  > this function. This would be extremely useful, as it would tell you
                  > exactly what had changed in either record, but this would also tend to
                  > eat up more room on your hard disk than most users would be willing to
                  > allow for genealogy record keeping. And there is another problem. Until
                  > the "February/March" release of NFS, AQ could download everything it
                  > might need to store for a typical record in about 8 seconds. After the
                  > "February/March" release of NFS, to get the same information from NFS
                  > would now take about 4-5 minutes. That's just for one relatively simple
                  > NFS record. (Complex NFS records would take much, much longer.) To
                  > record everything of value from NFS, for purposes of a later comparison
                  > review, now simply takes too long to be feasible. (Prior to the
                  > Feb/March release of NFS, AQ used to always read all the information
                  > from NFS so it would be ready for you. After the Feb/March release of
                  > NFS, AQ now reads everything but the notes and sources from NFS, and
                  > waits for you to ask for notes and sources before it retrieves them.
                  > Unless you take the time to look through all the notes and all the
                  > sources for an NFS record, you'll end up never retrieving the *entire*
                  > information on an NFS record with the newer builds of AQ.)
                  >
                  >> * If I review a record, find no changes, and exit without "saving" anything, what happens to the revision number? Will this record continue to show up?
                  >>
                  >>
                  > This depends, I believe, on whether you are reviewing from the "Check
                  > for Changes" screen, or from the Pedigree or Family view. I believe that
                  > if you review the record from the Check for Changes screen, the version
                  > number will be updated so that the next time you use the Check for
                  > Changes feature, it will not show up, unless another change has been
                  > made. However, if you review from the Pedigree or Family view, if you
                  > Close rather than Save, the version number will not be updated, so the
                  > next time you run the Check for Changes, the process will check against
                  > an older version number. You don't have to actually save anything --
                  > just use the "Save" button rather than the "Close" button to close this
                  > screen.
                  >
                  >> * Next, if I review a record with some changes, accept some of the changes (ie. temple work) but do not accept other changes (ie. birth/death dates or information on spouse/parents windows) and SAVE those changes, that this record will NOT show up the next time, even though there are still differences.
                  >>
                  >>
                  > Correct. Whether you accept any data from NFS at all, simply using the
                  > Save button to close this screen will indicate to AQ that you have
                  > reviewed it, and don't want to be reminded to look at it again until
                  > another change is made.
                  >
                  >> * Or if I make changes to my local database updating any of the information in an individual's record (and didn't update NFS at that time), nothing will highlight that my local record is different/updated.
                  >>
                  >>
                  > The Check for Changes feature only checks for changes on the NFS
                  > records, not for changes to your local records. To check for changes on
                  > your local records, use the "Change Log" feature in AQ. (This is found
                  > under the "Tools" menu. If you are using an AQ database, it keeps a very
                  > detailed log of your changes, but if you are using a PAF database, the
                  > log of changes is much more cryptic.)
                  >
                  >> Lastly, the problem with the corrupted files may be part of the problem. I get corrupted files on a regular basis and each time I will get 200-300 NFS record problems. No one has been able to tell me what the impact of that corruption was (until now). What I understood is that if the NFS information is lost on a record, then the version number reverts back to 0 and that record will show up next time I request a list of changes. Is that the only information that is lost with a corrupted NFS record?
                  >>
                  >>
                  > I think that sometimes when you get errors in the NFS portion of your
                  > file, some of the version numbers could be lost, and sometimes this may
                  > even cause the linkages between local records and NFS records to be lost
                  > -- meaning you'd have to link the records again. But most of the time, I
                  > think that there are no bad side-effects to having these NFS records
                  > reported in the Check/Repair process. In these cases, it is a matter of
                  > "house-cleaning" -- when AQ went to rewrite some NFS information, it
                  > wrote the new information and forgot to properly remove old data. In
                  > this case, the Check/Repair often simply completes the process of
                  > cleaning out old data that should have been removed earlier. If anyone
                  > finds a sequence of steps that causes these errors/warnings to show up
                  > in Check/Repair, we are very anxious hear of this so we can fix AQ to
                  > never again allow the NFS portion of the file to show problems in
                  > Check/Repair :-)
                  >
                  > Gaylon
                  >
                  >
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                • Stewart Millar
                  Something strange with the AQ Reserve Ordinance Window. I note that when a candidate is added to the list it brings across the Qualifying events with the
                  Message 8 of 22 , Jun 13, 2010
                    Something strange with the AQ Reserve Ordinance Window.



                    I note that when a candidate is added to the list it brings across the
                    "Qualifying" events with the associated date and place --- with the place
                    being the "standardised" place name.



                    I have several occurrences when for a selected individual on the list, the
                    qualifying event is "Birth" and it correctly displays the birth date but has
                    the place name left blank. For these individuals, there is actually a
                    standardised place name present. Why is it not being brought across?



                    Let me give you an example from nFS:



                    Name: Maria Ward

                    nFS PID: L7BG-5QQ



                    This example is from a ward member I am assisting as a fh consultant.



                    In the "Details" window you will note the "entered" place name is "St
                    Saviour, Southwark, Surrey, England" --- hovering the cursor over the
                    entered place name will display the "standardised" place name as "Southwark,
                    Surrey, England, United Kingdom" (or alternatively using the edit button to
                    display the details, but of course will tell you cannot edit this entry).



                    On the majority of my entries in the Reserve Ordinance window (about 60%) it
                    is getting it right with the standardised place name being brought across -
                    but for the remaining 40% of entries, despite their being a standardised
                    place name present, it has the place name blank in this Reserve Ordinance
                    window.



                    Any suggestions?



                    And --- will it give me a problem further down the line, in that the minimum
                    requirement for submissions is a name, date and place and here the proposed
                    submission is showing without a place.



                    === Stewart



                    [Non-text portions of this message have been removed]
                  • Tom Huber
                    ... The Church recently added a considerable number of places to the list, many of which have more than four political divisions. I ve noticed that when the
                    Message 9 of 22 , Jun 13, 2010
                      On Mon, 14 Jun 2010 02:45:33 +0100, you wrote:

                      >Something strange with the AQ Reserve Ordinance Window.

                      >I have several occurrences when for a selected individual on the list, the
                      >qualifying event is "Birth" and it correctly displays the birth date but has
                      >the place name left blank. For these individuals, there is actually a
                      >standardised place name present. Why is it not being brought across?
                      >
                      The Church recently added a considerable number of places to the list,
                      many of which have more than four political divisions. I've noticed
                      that when the place has more than four political divisions, the place
                      is not brought into the AQ Reserve Ordinance Window.

                      Hope this helps.

                      Tom
                    • Stewart Millar
                      Thanks Tom - but in this case both the entered and standard (assigned by nFS) have each only 4 divisions. === Stewart From: AQ_NFS@yahoogroups.com
                      Message 10 of 22 , Jun 13, 2010
                        Thanks Tom - but in this case both the "entered" and "standard" (assigned by
                        nFS) have each only 4 divisions.



                        === Stewart







                        From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of
                        Tom Huber
                        Sent: 14 June 2010 02:52
                        To: AQ_NFS@yahoogroups.com
                        Subject: Re: [AQ_NFS] AQ Reserve Ordinance Window occasional problem with
                        Standard Place Names





                        On Mon, 14 Jun 2010 02:45:33 +0100, you wrote:

                        >Something strange with the AQ Reserve Ordinance Window.

                        >I have several occurrences when for a selected individual on the list, the
                        >qualifying event is "Birth" and it correctly displays the birth date but
                        has
                        >the place name left blank. For these individuals, there is actually a
                        >standardised place name present. Why is it not being brought across?
                        >
                        The Church recently added a considerable number of places to the list,
                        many of which have more than four political divisions. I've noticed
                        that when the place has more than four political divisions, the place
                        is not brought into the AQ Reserve Ordinance Window.

                        Hope this helps.

                        Tom





                        [Non-text portions of this message have been removed]
                      • Gunilla Manell
                        I am not sure it what I have seen is the same thing or not, but when I add a person to the Reserve ordinances screen, before he or she has been linked, the
                        Message 11 of 22 , Jun 13, 2010
                          I am not sure it what I have seen is the same thing or not, but when I add a
                          person to the Reserve ordinances screen, before he or she has been linked,
                          the place name shows. As soon as the link is complete, in most cases, the
                          place name disappears.



                          I have been wondering about this also, but it has been doing it ever since I
                          started using AQ to reserve names. I have been doing it since a year ago,
                          when my temple district finally got access to nFS.



                          However in most cases, the cards print out OK including place names. And I
                          say MOST, because sometimes it links up with a name that is not the
                          preferred name, it even ignores the date I have uploaded and submitted, and
                          the name may have become abbreviated instead of the spelled out name that I
                          have uploaded. I sure wish the cards would print out with the complete
                          information that I have submitted.



                          /Gunilla





                          From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of
                          Stewart Millar
                          Sent: Sunday, June 13, 2010 7:46 PM
                          To: AQ_NFS@yahoogroups.com
                          Subject: [AQ_NFS] AQ Reserve Ordinance Window occasional problem with
                          Standard Place Names





                          Something strange with the AQ Reserve Ordinance Window.

                          I note that when a candidate is added to the list it brings across the
                          "Qualifying" events with the associated date and place --- with the place
                          being the "standardised" place name.

                          I have several occurrences when for a selected individual on the list, the
                          qualifying event is "Birth" and it correctly displays the birth date but has
                          the place name left blank. For these individuals, there is actually a
                          standardised place name present. Why is it not being brought across?

                          Let me give you an example from nFS:

                          Name: Maria Ward

                          nFS PID: L7BG-5QQ

                          This example is from a ward member I am assisting as a fh consultant.

                          In the "Details" window you will note the "entered" place name is "St
                          Saviour, Southwark, Surrey, England" --- hovering the cursor over the
                          entered place name will display the "standardised" place name as "Southwark,
                          Surrey, England, United Kingdom" (or alternatively using the edit button to
                          display the details, but of course will tell you cannot edit this entry).

                          On the majority of my entries in the Reserve Ordinance window (about 60%) it
                          is getting it right with the standardised place name being brought across -
                          but for the remaining 40% of entries, despite their being a standardised
                          place name present, it has the place name blank in this Reserve Ordinance
                          window.

                          Any suggestions?

                          And --- will it give me a problem further down the line, in that the minimum
                          requirement for submissions is a name, date and place and here the proposed
                          submission is showing without a place.

                          === Stewart

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





                          [Non-text portions of this message have been removed]
                        • Tom Huber
                          ... The other thing that I ve noticed is that if the summary in nFS does not show a place, then the AQ Reserve Ordinance Window is also missing the place. I
                          Message 12 of 22 , Jun 13, 2010
                            On Mon, 14 Jun 2010 03:06:07 +0100, you wrote:

                            >Thanks Tom - but in this case both the "entered" and "standard" (assigned by
                            >nFS) have each only 4 divisions.
                            >
                            The other thing that I've noticed is that if the summary in nFS does
                            not show a place, then the AQ Reserve Ordinance Window is also missing
                            the place. I have to go into nFS manually and select the place for it
                            to show. I don't know if Gaylon can do anything for the AQ Reserve
                            Ordinance Window to use the place we have in our AQ/PAF file or if it
                            will always default to the Summary View in nFS.

                            You may want to play around with the Summary view to see if it makes
                            any difference in the AQ Reserve Ordinance Window.

                            Tom
                          • Stewart Millar
                            I continue to have a queasy feeling about the missing standard place name in the Reserve Ordinance window (ROW). As these missing place names do not reflect
                            Message 13 of 22 , Jun 15, 2010
                              I continue to have a queasy feeling about the missing "standard" place name
                              in the Reserve Ordinance window (ROW).



                              As these missing place names do not reflect the situation in nFS - they
                              therefore must indicate a problem in AQ.



                              In further experiments I was able to alter an entry in the ROW which
                              initially was displaying a standard place name - but it was an incorrect
                              choice of standard place name - for an "entered" place name of "Cork,
                              Ireland" it was displaying "Corcaigh, Ireland" i.e., using the Irish Gaelic
                              name for "Cork" ------ so from the ROW I went into nFS and changed the
                              standard name to the valid alternative standard place name of "Cork,
                              Ireland" ---- on returning to the ROW, the previously displayed standard
                              name disappeared with no replacement.



                              An explanation scenario might be ----- this record was synched to nFS using
                              AQ --- in doing so, AQ must have found and assigned the initial "standard"
                              place name. It now seems to me that any time the "standard" name that was
                              initially assigned via AQ is changed, the ROW becomes unable to find and
                              display the existing "standard" place name from nFS.



                              Any comment from Gaylon or the techies?



                              === Stewart



                              [Non-text portions of this message have been removed]
                            • emregister
                              Yesterday a patron came to the FHC. She had two 3.5 inch floppy disks with data from the 1980s. Fortunately she had a USB stick with her. To transfer the
                              Message 14 of 22 , Oct 6, 2010
                                Yesterday a patron came to the FHC. She had two 3.5 inch floppy disks with
                                data from the 1980s. Fortunately she had a USB stick with her. To transfer
                                the data to the USB stick was straight forward. The patron intended to use
                                PAF but the data format was filename.dat and PAF did not recognize it. So..
                                AQ to the rescue. AQ recognized the data instantly and configured it to AQ
                                data. Then we asked AQ to configure the data for PAF. All was well and
                                took very little time. She left a very happy patron. Thanks AQ.



                                Eric



                                [Non-text portions of this message have been removed]
                              • emregister
                                On a regular bases I review all batch files. There is a column completed which will contain some X s. I would expect that all ordinances that have been
                                Message 15 of 22 , Oct 6, 2010
                                  On a regular bases I 'review' all batch files. There is a column
                                  'completed' which will contain some 'X's. I would expect that all
                                  ordinances that have been reserved have been completed if there is an X in
                                  the completed column. However, many times the X is there but the ordinances
                                  are not yet completed. Any ideas/comments?



                                  Eric



                                  [Non-text portions of this message have been removed]
                                • Donald R. Snow
                                  Many people aren t aware that all the earlier version of PAF are on the PAF CD that you get from the Distribution Centers and they are made so that they
                                  Message 16 of 22 , Oct 6, 2010
                                    Many people aren't aware that all the earlier version of PAF are on
                                    the PAF CD that you get from the Distribution Centers and they are made
                                    so that they install in Windows. Using that any PAF database from an
                                    earlier version can be opened in the appropriate PAF version and then
                                    you can make a GEDCOM and import it into any newer genealogy program
                                    that takes GEDCOM's. I haven't used AQ to upgrade from an older PAF
                                    version, but I lost lots of links when I did the automatic upgrade in
                                    PAF 4 and 5, so I don't recommend the automatic upgrade, but I use the
                                    GEDCOM route.

                                    Don


                                    On 10/6/2010 10:03 PM, emregister wrote:
                                    >
                                    >
                                    >
                                    > Yesterday a patron came to the FHC. She had two 3.5 inch floppy disks with
                                    > data from the 1980s. Fortunately she had a USB stick with her. To transfer
                                    > the data to the USB stick was straight forward. The patron intended to use
                                    > PAF but the data format was filename.dat and PAF did not recognize it.
                                    > So..
                                    > AQ to the rescue. AQ recognized the data instantly and configured it to AQ
                                    > data. Then we asked AQ to configure the data for PAF. All was well and
                                    > took very little time. She left a very happy patron. Thanks AQ.
                                    >
                                    > Eric
                                    >
                                    > [Non-text portions of this message have been removed]
                                    >
                                    >

                                    --
                                    Dr. Donald R. Snow, Retired Professor of Mathematics, Brigham Young University, Provo, Utah - snowd@...



                                    [Non-text portions of this message have been removed]
                                  • Gunilla Manell
                                    From what I have seen with my data, when all ordinances that were cleared and printed on a card had been completed, the X would show the all ordinances on the
                                    Message 17 of 22 , Oct 7, 2010
                                      From what I have seen with my data, when all ordinances that were cleared
                                      and printed on a card had been completed, the X would show the all
                                      ordinances on the card were done.

                                      If you haven't cleared seal to parents yet, then you still need to perform
                                      that from a different card. Sealing to spouse is done from a different card
                                      also.



                                      I have not yet seen what you apparently have experienced. Just a thought,
                                      did you update all, to transfer the dates to your database after ordinances
                                      were performed?



                                      /Gunilla



                                      From: AQ_NFS@yahoogroups.com [mailto:AQ_NFS@yahoogroups.com] On Behalf Of
                                      emregister
                                      Sent: Wednesday, October 06, 2010 10:11 PM
                                      To: AQ_NFS@yahoogroups.com
                                      Subject: [AQ_NFS] Bath files are marked 'complete' but are not







                                      On a regular bases I 'review' all batch files. There is a column
                                      'completed' which will contain some 'X's. I would expect that all
                                      ordinances that have been reserved have been completed if there is an X in
                                      the completed column. However, many times the X is there but the ordinances
                                      are not yet completed. Any ideas/comments?

                                      Eric

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





                                      [Non-text portions of this message have been removed]
                                    • emregister
                                      This occurs with records that were reserved for the temple. If all ordinances were not reserved this does not appear to affect the X . It does not appear
                                      Message 18 of 22 , Oct 7, 2010
                                        This occurs with records that were reserved for the temple. If all
                                        ordinances were not reserved this does not appear to affect the 'X'. It
                                        does not appear to be related to 'updating'.



                                        Eric

                                        Subject: RE: [AQ_NFS] Bath files are marked 'complete' but are not





                                        From what I have seen with my data, when all ordinances that were cleared
                                        and printed on a card had been completed, the X would show the all
                                        ordinances on the card were done.

                                        If you haven't cleared seal to parents yet, then you still need to perform
                                        that from a different card. Sealing to spouse is done from a different card
                                        also.

                                        I have not yet seen what you apparently have experienced. Just a thought,
                                        did you update all, to transfer the dates to your database after ordinances
                                        were performed?

                                        /Gunilla

                                        From: AQ_NFS@yahoogroups.com <mailto:AQ_NFS%40yahoogroups.com>
                                        [mailto:AQ_NFS@yahoogroups.com <mailto:AQ_NFS%40yahoogroups.com> ] On Behalf
                                        Of
                                        emregister
                                        Sent: Wednesday, October 06, 2010 10:11 PM
                                        To: AQ_NFS@yahoogroups.com <mailto:AQ_NFS%40yahoogroups.com>
                                        Subject: [AQ_NFS] Bath files are marked 'complete' but are not

                                        On a regular bases I 'review' all batch files. There is a column
                                        'completed' which will contain some 'X's. I would expect that all
                                        ordinances that have been reserved have been completed if there is an X in
                                        the completed column. However, many times the X is there but the ordinances
                                        are not yet completed. Any ideas/comments?

                                        Eric

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

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





                                        [Non-text portions of this message have been removed]
                                      Your message has been successfully submitted and would be delivered to recipients shortly.