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

False positives using "Check for changes" option

Expand Messages
  • ChinaBob
    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
    Message 1 of 22 , Jun 9, 2010
    • 0 Attachment
      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.
    • Ken Doyle
      Dear Bob and Gaylon, Thanks for that. I did not know about that button. I have recently felt that was needed. Nevertheless it seems it was already there. THANK
      Message 2 of 22 , Jun 10, 2010
      • 0 Attachment
        Dear Bob and Gaylon,

        Thanks for that. I did not know about that button. I have recently felt that was needed. Nevertheless it seems it was already there.

        THANK YOU VERY MUCH.

        Cheers,

        Ken

        --- In AQ_NFS@yahoogroups.com, "ChinaBob" <robert.l.scott@...> 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.
        >
      • Dee Whiting
        I m sorry, but I didn t understand the solution. Can you please resend? I don t see a reply from Bob and Gaylon. Thank you in advance, Dee From:
        Message 3 of 22 , Jun 10, 2010
        • 0 Attachment
          I'm sorry, but I didn't understand the solution. Can you please resend? I
          don't see a reply from Bob and Gaylon.

          Thank you in advance,

          Dee



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





          Dear Bob and Gaylon,

          Thanks for that. I did not know about that button. I have recently felt that
          was needed. Nevertheless it seems it was already there.

          THANK YOU VERY MUCH.

          Cheers,

          Ken

          --- In AQ_NFS@yahoogroups.com <mailto:AQ_NFS%40yahoogroups.com> , "ChinaBob"
          <robert.l.scott@...> 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.



          .


          <http://geo.yahoo.com/serv?s=97359714/grpId=25229696/grpspId=1709334992/msgI
          d=544/stime=1276186154/nc1=6083913/nc2=4507179/nc3=3848644>





          [Non-text portions of this message have been removed]
        • Gaylon Findlay
          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
          Message 4 of 22 , Jun 10, 2010
          • 0 Attachment
            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
            >
            >
            >
            >
            >
          • 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 5 of 22 , Jun 10, 2010
            • 0 Attachment
              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 6 of 22 , Jun 11, 2010
              • 0 Attachment
                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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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.