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

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

Expand Messages
  • 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 1 of 22 , Jun 11, 2010
    • 0 Attachment
      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 2 of 22 , Jun 11, 2010
      • 0 Attachment
        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 3 of 22 , Jun 11, 2010
        • 0 Attachment
          > 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 4 of 22 , Jun 11, 2010
          • 0 Attachment
            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 5 of 22 , Jun 11, 2010
            • 0 Attachment
              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 6 of 22 , Jun 13, 2010
              • 0 Attachment
                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 7 of 22 , Jun 13, 2010
                • 0 Attachment
                  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 8 of 22 , Jun 13, 2010
                  • 0 Attachment
                    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 9 of 22 , Jun 13, 2010
                    • 0 Attachment
                      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 10 of 22 , Jun 13, 2010
                      • 0 Attachment
                        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 11 of 22 , Jun 15, 2010
                        • 0 Attachment
                          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 12 of 22 , Oct 6, 2010
                          • 0 Attachment
                            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 13 of 22 , Oct 6, 2010
                            • 0 Attachment
                              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 14 of 22 , Oct 6, 2010
                              • 0 Attachment
                                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 15 of 22 , Oct 7, 2010
                                • 0 Attachment
                                  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 16 of 22 , Oct 7, 2010
                                  • 0 Attachment
                                    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.