1 2 Previous Next 18 Replies Latest reply on Jan 11, 2010 2:09 AM by comment_1

    Error trapping strangeness

    RickWhitelaw

      Title

      Error trapping strangeness

      Post

      I'm having an issue that the script below resolves.(!) The strange thing is that, originally, the seventh line down was If[Get(LastError)=401] and, even if the find came up empty, there was no Error 401 returned. This defeated the whole purpose of the routine. Everything else worked fine (Script Parameter etc.). Ideas? Either I'm missing something dead obvious (I've done this TOO many times) or something is odd. BTW, I know that if I use the script as it is below, I can ditch the error capturing.

       

      RW 

       

      New Window [ Top: 800 ]

      Go to Layout [ “Associate Contractor Details” (ASST_MAN_FEE) ]

      Set Error Capture [ On ]

      Enter Find Mode [ ]

      Set Field [ ASST_MAN_FEE::PROD_DAT; Get ( ScriptParameter ) ]

      Perform Find [ ]

      If [ Get ( FoundCount ) = 0 ]

      Show Custom Dialog [ Message: "There is no Assistant listed for this engagement and date."; Buttons: “Exit” ] If [ Get ( LastMessageChoice ) = 1 ]

      Close Window [ Current Window ]

      Exit Script [ ]

      End If

      End If

        • 1. Re: Error trapping strangeness
          LaRetta_1
            

          Hi Rick, you can be biten by this issue either way.  For example (table with 10 records), if you enter invalid value in search field, either testing for error 401 or Get ( FoundCount ) = 0 should produce consistent results as you expect.  But other errors can be thrown and they will not even perform the find and you won't even know the find didn't work!  The failure could be 400 (no find criteria), such as if you fired the script from ScriptMaker instead of the button or your global which holds the find criteria is blank.  When the find doesn't take place, you will be left with the same record status as when you started.

           

          You can verify this by using a global instead of script parameter and leave it blank.  The Status Area (Status Toolbar) if there is find criteria, will display two items:  Found: # and Total: #.  But if your find fails because the find criteria is blank (and you start with all records showing) the Status Area will only show Total: 10 and no Found: # like when the find succeeds.  Conversely, if you have 0 found set when you start, it will leave you with Found: 0 and Total: 10 so you can't even trust testing for 0 found alone.

           

          In other words, if you trap for errors, you had better trap well (or use simply use If [ Get ( LastError ) ] which produces boolean true no matter why it fails, or make sure your script parameter (or global) is never empty or if paused for User entry, that you test for 400 or that they entered something.. :smileyhappy:

           

          UPDATE:  This discussion is based upon having Set Error Capture [ On ] and means that it is up to us to consider all possibilities.  I don't always do it either and I've been caught by it at times.  :smileyindifferent:

          • 2. Re: Error trapping strangeness
            RickWhitelaw
              

            LaRetta,

             

            Thanks for the reply. However the search criteria is not blank and no other errors are reported in the debugger. As you can see, error capture  is on.  If I do this search manually I DO get the usual message if there's nothing found. That's what makes this a mystery. As far as using an unqualified Get(LastError) goes, I try to be more specific when trapping errors. In this case, given the Script Parameter is intact (it is) the only possible error is 401 so there's no reason to trap for others. When I debug this very simple script I can see the field being Set correctly in Find Mode, the find is performed and an "empty" record is displayed, but no error is returned. Also bear in mind this script is being fired from a different layout so in real time all I see is an "empty" record show up on the "new" layout.

            When I say "this script" I mean the same script with "Get(LastError)" instead of "Get(FoundCount)". 

            In this case either of the above steps should effectively produce the same result . . . one via error capture, the other by simple evaluation. I just tried it again and the error trapping is simply not working.

            I could also use GTRR and trap for error 101, but it seems the original script should work. 

            Ahaa . . . I just triggered the script after removing the Set Error capture step, and the usual FM dialog came up telling me of no match. This happens with either of the above steps, so it's not trapping 401. 

            • 3. Re: Error trapping strangeness
              comment_1
                 Why don't you turn error capture on and pop up a custom dialog with Get(LastError) - so that you'll see what error IS returned.
              • 4. Re: Error trapping strangeness
                RickWhitelaw
                   Wouldn't I see the error in the script debugger before the "If Get(LastError)" step is performed?
                • 5. Re: Error trapping strangeness
                  RickWhitelaw
                    

                  Comment,

                   

                  I tried your suggestion anyway and it simply doesn't capture the error (or any error) even though there is no record found. This is getting to be academic since the "Get(FoundCount)" works fine, but the fact that it won't trap 401 is intriguing.

                   

                  RW 

                  • 6. Re: Error trapping strangeness
                    comment_1
                       In theory yes, but sometimes the debugger can interfere. It doesn't seem to be working according to theory anyway. Your file could be corrupted - try it with a new file or a recovered copy.
                    • 7. Re: Error trapping strangeness
                      RickWhitelaw
                        

                      Comment,

                       

                      I did a recover on the file, plus several recent backups. The following seem to be the only 2 relevant messages. However, when I check the body of the log, there's nothing. All indexes rebuilt with 0 changes. 2 items modified . . . I found one (missing function) and ran recover again. This time only 1. Here's what the log says:

                       

                      WARNING: problems were detected while recovering the database.  The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file.

                       

                      2010-01-09 21:50:52.083 -0500 Production.fp7 0 Structure: scanned; 2 item(s) modified

                       

                       

                      I'm uncertain what to do. I'll find the other "modification" and run it again I suppose. 

                       


                      • 8. Re: Error trapping strangeness
                        RickWhitelaw
                          

                        It was apparently a corrupt layout. I made a new one, copied the objects over, and voila!

                         

                        This is a new one for me. I've built hundreds of layouts and never had one corrupt like that. The file has never been improperly closed or crashed either. . . . 

                         

                        Thanks. 

                        • 9. Re: Error trapping strangeness
                          StellaLuna
                            

                          RickWhitelaw wrote:

                          In this case either of the above steps should effectively produce the same result . . . one via error capture, the other by simple evaluation.

                           

                          As far as using an unqualified Get(LastError) goes, I try to be more specific when trapping errors. In this case, given the Script Parameter is intact (it is) the only possible error is 401 so there's no reason to trap for others. 



                          If you are instead searching a related table and, even if your script paramater is in tact, the other table might have corrupted, you will instead receive 508 (Invalid value entered in find mode).  In this case, as explained, you will not get 401, your find will appear to work  but you will have a found count (your original set) and your script can act upon incorrect main records. 


                          RickWhitelaw wrote:
                          BTW, I know that if I use the script as it is below, I can ditch the error capturing.

                          Well, I'm glad you are so confident. You were being warned against such firm beliefs; use the input or don't.

                           



                          • 10. Re: Error trapping strangeness
                            StellaLuna
                              

                            "It was apparently a corrupt layout. I made a new one, copied the objects over, and voila!"

                             

                            Oh Rick, a file should never be used after it has been recovered. And the log even gave you the warning!  Even if a file hasn't been improperly closed, it can corrupt.  (missing function) usually indicates that a custom function has trashed out.  Even copying objects from a corrupt layout to a new layout can bring the trash over through the objects themselves.

                             

                            I would never trust a file which has been recovered nor ever copy over objects or scripts from a recovered file. 

                            • 11. Re: Error trapping strangeness
                              LaRetta_1
                                 <!--     [if gte mso 9]&amp;amp;amp;gt;&amp;amp;amp;lt;xml&amp;amp;amp;gt; &amp;amp;amp;lt;w:LatentStyles DefLockedState=&amp;amp;amp;quot;false&amp;amp;amp;quot; LatentStyleCount=&amp;amp;amp;quot;156&amp;amp;amp;quot;&amp;amp;amp;gt; &amp;amp;amp;lt;/w:LatentStyles&amp;amp;amp;gt; &amp;amp;amp;lt;/xml&amp;amp;amp;gt;&amp;amp;amp;lt;![endif]     --><!--     /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal      {mso-style-parent:&amp;amp;amp;quot;&amp;amp;amp;quot;;      margin:0in;      margin-bottom:.0001pt;      mso-pagination:widow-orphan;      font-size:12.0pt;      font-family:&amp;amp;amp;quot;Times New Roman&amp;amp;amp;quot;;      mso-fareast-font-family:&amp;amp;amp;quot;Times New Roman&amp;amp;amp;quot;;} p      {mso-margin-top-alt:auto;      margin-right:0in;      mso-margin-bottom-alt:auto;      margin-left:0in;      mso-pagination:widow-orphan;      font-size:12.0pt;      font-family:&amp;amp;amp;quot;Times New Roman&amp;amp;amp;quot;;      mso-fareast-font-family:&amp;amp;amp;quot;Times New Roman&amp;amp;amp;quot;;} @page Section1      {size:8.5in 11.0in;      margin:1.0in 1.25in 1.0in 1.25in;      mso-header-margin:.5in;      mso-footer-margin:.5in;      mso-paper-source:0;} div.Section1      {page:Section1;}      --><!--     [if gte mso 10]&amp;amp;amp;gt; &amp;amp;amp;lt;style&amp;amp;amp;gt; /* Style Definitions */ table.MsoNormalTable      {mso-style-name:&amp;amp;amp;quot;Table Normal&amp;amp;amp;quot;;      mso-tstyle-rowband-size:0;      mso-tstyle-colband-size:0;      mso-style-noshow:yes;      mso-style-parent:&amp;amp;amp;quot;&amp;amp;amp;quot;;      mso-padding-alt:0in 5.4pt 0in 5.4pt;      mso-para-margin:0in;      mso-para-margin-bottom:.0001pt;      mso-pagination:widow-orphan;      font-size:10.0pt;      font-family:&amp;amp;amp;quot;Times New Roman&amp;amp;amp;quot;;      mso-ansi-language:#0400;      mso-fareast-language:#0400;      mso-bidi-language:#0400;} &amp;amp;amp;lt;/style&amp;amp;amp;gt; &amp;amp;amp;lt;![endif]     -->

                              Thanks, Stella, I was indeed addressing the principle that Rick thought he was protected (either by only using 401 or 0 found count) and he probably isn't.

                               

                              Rick, with your corrupt layout, if error capture was on before the layout switch, you might have gotten a 105 (Layout is missing) or if the first table occurrence was related to the second, you could even get 103 (Relationship is missing) and it might have told you that your layout was broken.  With that information, you could have aborted the find instead.  In either instance, you would have remained on the current layout, potentially working on a found set which was incorrect and might have even been the wrong table.

                               

                              I wasn't clear, I guess.  I was suggesting that many protections be in place and I wasn't going to provide a generic solution to the issue because I don't believe protections can be generic so I just threw out some concerns and issues (as I see them).  But I DO think we should consider these types of breaks very seriously every time we script.  A generic approach, which should work well even * pre-vs. 10 with the changes in error capture) would be something like:

                               

                              Set Error Capture [ On ]

                              Go To Layout [ whatever ]

                              Set Variable [ $error ; $error & Get ( LastError ) & ¶ ]

                              Enter Find Mode [ ]

                              Set Field [ ASST_MAN_FEE::PROD_DAT ; Get ( ScriptParameter ) ]

                              Set Variable [ $error ; $error & Get ( LastError ) & ¶ ]

                              Perform Find [ ]

                              Set Variable [ $error ; $error & Get ( LastError ) & ¶ ]

                              If [ /* serious error */  ValueCount ( $error ) - ValueCount ( FilterValues ( $error ; "0¶401¶400"  ) ) ]

                              Show Custom Dialog [ Exit ; “ERROR” ; "Notify your administrator immediately that there is a problem with this process." ]

                              Else If [ /* No records found */  Position ( $error ; 401 ; 1 ; 1 ) ]

                              Show Custom Dialog [ Exit ; “No records found.”  ]

                              Else If [ /* No find criteria */  Position ( $error ; 400 ; 1 ; 1 ) ]

                              Show Custom Dialog [ Exit ; “You didn’t enter any find criteria.  Try again.”  ]

                              Else

                              … you have success … run your process here

                              End If

                              Go To Layout [ original layout ]

                               

                              You will notice that I trapped almost every script-step into a variable multi-line.  Yes I know, it seems like overkill.  But if I first look for 401 and ignore other possible errors, I could miss serious problems.  And until FileMaker provides us a way of trapping ALL errors in a multiline and until FileMaker tells us exactly which script steps can ever possibly produce which error codes, we must do it ourselves.  And I could have stopped the script when the layout break was indicated.  But some error messages are very serious but wouldn't happen until AFTER the milder 401 tests.  So I capture ALL and then run my test sequence before I continue with my actions (whenever I can), modifying the blue step above (calculation) and the following Else Ifs as needed.  And no, this won't fit every situation but even this 'generic' approach will protect from the unforseen much more than simple 401 or 0 found count.

                               

                              UPDATE:   I forgot to explain the * above ...The following Control script steps no longer clear the last error condition in vs. 10: If, Else, Else If, End If, Loop, Exit Loop If, End Loop, Exit Script and Halt Script.  We won't need to store the error codes into variable if we plan on addressing the specific code immediately, but I prefer grabbing them all first. 

                               

                              This may not be applicable in your case, Rick, but I thought it might be important to mention.  It's like going into a grocery store.  If you need tea, you take it; if you don't, you walk on by.  You don't yell at the store keeper nor do you leave the store in disgust for showing you tea on the shelf.  I just showed you the tea.   :smileyhappy:

                              • 12. Re: Error trapping strangeness
                                RickWhitelaw
                                  

                                Stella,

                                 

                                Perhaps I wasn't clear. I would never use a file after it's been recovered. However, examining the recovery log can give some clues as to what's wrong, which is how I used it. The corrupt layout was, of course, in the original file, and has been removed. In the original file, a new layout was created, objects placed in it, and the old layout deleted. All this, of course, in the original file. The problem disappeared.

                                 

                                RW 

                                • 13. Re: Error trapping strangeness
                                  RickWhitelaw
                                    

                                  Laretta,

                                   

                                  Thanks for the trapping ideas. I agree with you and routinely trap for multiple errors. In this case I was mystified by the lack of 401 trapping which seems to have been caused by corruption. Also, I was quite certain of the layout's existence, the relationship, the search criteria etc. Thankfully this script did  (or used to do) nothing but display a certain layout for further (manual) input.

                                   The other thing I forgot to mention in this reply: the debugger wasn't returning ANY errors and I knew this wasn't possible since there were no found records. Now that the layout is fixed I'll implement more trapping so the script can be used in ohter contexts safely.

                                  RW 

                                  • 14. Re: Error trapping strangeness
                                    RickWhitelaw
                                      

                                    Stella Luna wrote:

                                     

                                    "Well, I'm glad you are so confident. You were being warned against such firm beliefs; use the input or don't."

                                     

                                    Stella,

                                     

                                    If FM was not trapping 401 or any other error, in this context I could indeed turn off error capture and witness no difference in behavior. The Get(RecordCount) would evaluate the situation as expected. I should have been clearer that this behavior was unacceptable, but then again, that was kind of the subject that started the thread, no?

                                    Regarding your quote above, if I had the intention of ignoring the input users contribute to this forum, I don't understand why I would spend the time posting questions as well as attempting to answer the questions of others. As well, and I'm sure you know this, sometimes a poster is attempting to deal with an issue in between posting observations/questions and in this case the process was moving at quite a clip. I may have been less than crystal-clear on a couple of points. I'm not sure this makes your comments any more appropriate. Anyway, all good.

                                     

                                    RW 

                                      

                                    1 2 Previous Next