10 Replies Latest reply on May 11, 2009 1:06 PM by philmodjunk

    onRecordLoad oddity

    _ian

      Summary

      onRecordLoad oddity

      Description of the issue

      I'm still undecided if this is a bug or not. I think at the very least it's an omission in the implementation of script triggers. One of our guys picked up an interesting little bug today.He was using get(lasterror) to check the results of a find and discovered that he was getting error code 0 in situations he was expecting an error code. It turns out that he's been using an OnRecordLoad fired script. His scripted find returns 0 records due to a 401 error, but OnRecordLoad fires even though there is no record to load. As soon as the event fires it seems to be clearing get(lasterror) before he can populate his $last_error variable because it is evaluating script steps. tracing in script debugger you can see the error code, but there seems to be no way to retrieve it in a script.So onRecordLoad is firing even if there are no records in the found set to load. The problem is that it seems to prevent any effective way of capturing errors from a failed Find script step. It only leaves us with checkiing the found count, which while it lets us know that there are no records, it's not very helpful in determining *why* we've got no records returned from a Find. It would be extremely useful to have some means of returning a result from a script trigger. But this would presumably require redoing script triggers to function more like events in other programming languages. Which would be a really really good thing, but I do realise isn't going to happen anytime soon.  regardsIan  

        • 1. Re: onRecordLoad oddity
          TSGal

          _ian:

           

          Thank you for your post.

           

          Once the Find is performed, then the OnRecordLoad is triggered.  Even if no records are found, FileMaker Pro displays record zero.  One of the reasons for the OnRecordLoad would be to deal with global fields which are accessible from record zero.  You can either use Get (FoundCount) for zero records, or perform the find in another layout, and then put the LastError result into a variable before switching to the desired layout.

           

          TSGal

          FileMaker, Inc. 

          • 2. Re: onRecordLoad oddity
            philmodjunk
               To avoid unintentionally performing scripts through such script triggers, I've found it useful to set up blank layouts to use when I need a script to establish a different table context such as the situtation you discribe in this thread.
            • 3. Re: onRecordLoad oddity
              _ian
                
              Thanks TSGal
               
              A quick straw poll suggests that most people think that OnRecordLoad should not fire when there are no records in the found set. But it sounds like there is a valid reason for that. 
               
              However, the fact that get(lasterror) cannot be relied upon to return the correct last error is definitely a bug. get(lasterror) should return the last error in the script that it is run from. If that's not the intended behaviour, then I suppose it's a really critical feature request. Without the ability to rely on get(lasterror)  it becomes very difficult to develop a sound robust database system.
              There are work-arounds for the specific issue of Finds but they're very unwieldy and only get us part of the way there. Checking for no records in the found set is only a partial solution, since it doesn't tell us why there are no records. Navigating to another layout to perform a find and then back again will work. Adding another 75-80 layouts to an average sized system to support a work-around for a bug doesn't seem like a very appealing prospect. 
               
              kind regards
              Ian 

              TSGal wrote:

              _ian:

               

              Thank you for your post.

               

              Once the Find is performed, then the OnRecordLoad is triggered.  Even if no records are found, FileMaker Pro displays record zero.  One of the reasons for the OnRecordLoad would be to deal with global fields which are accessible from record zero.  You can either use Get (FoundCount) for zero records, or perform the find in another layout, and then put the LastError result into a variable before switching to the desired layout.

               

              TSGal

              FileMaker, Inc. 


               


              • 4. Re: onRecordLoad oddity
                philmodjunk
                  

                "Adding another 75-80 layouts to an average sized system to support a work-around for a bug doesn't seem like a very appealing prospect."

                Unless you have 75-80 different tables and all your existing layouts use this script trigger, you won't need this many layouts. You should only need to create a blank layout that refers to one specific table on an "as needed" basis. I think you'll find that's a much smaller number of additional layouts.

                 

                With that said, I agree that Filemaker's "Layout sensitivity" is a problem--one that has persisted through many different versions. The latest, multi-table versions have exacerbated this issue. I've already posted to the suggestion form the following future feature request:

                 

                Filemaker scripts need the ability to establish a "table context" without navigating to a specific layout. The syntax could look something like this:

                 

                Set Table Context [TableName]

                .

                .

                .

                .

                End Table Context

                 

                All enclosed script steps would execute as though the script had navigated to a specific layout, but without actually doing so. Among other benefits, no layout script trigger events would take place.

                • 5. Re: onRecordLoad oddity
                  _ian
                    
                  That's an excellent idea! Something along those lines would save loads of time and code...
                   Ian 

                  PhilModJunk wrote:


                  With that said, I agree that Filemaker's "Layout sensitivity" is a problem--one that has persisted through many different versions. The latest, multi-table versions have exacerbated this issue. I've already posted to the suggestion form the following future feature request:

                   

                  Filemaker scripts need the ability to establish a "table context" without navigating to a specific layout. The syntax could look something like this:

                   

                  Set Table Context [TableName]

                  .

                  .

                  .

                  .

                  End Table Context

                   


                   


                  • 6. Re: onRecordLoad oddity
                    philmodjunk
                       Perhaps if other like minded users made the same or similar requests it might encourage filemaker to make this change a priority? :smileywink:
                    • 7. Re: onRecordLoad oddity
                      deltatango
                        

                      Set Table Contents script step would be fantastic!

                       

                      Another thing that could go along with this, and to me would be a great help, is if the list of tables in a dialog were color-coded to match the colors that you assign the table occurences in the relationships tab in the manage database dialog.

                       

                      Would be so much easier to "see" a distinction in your tables.

                      • 8. Re: onRecordLoad oddity
                        philmodjunk
                          

                        That "color coding" would be a great option!

                         

                        Have you put it in that irritating Feature Request form that the Filemaker Tech folks keep telling us to use? The way I see it, any time some one reads a feature suggestion here that they like, they should click over to that form and make the same request there. That way we are "buzzing up" the suggestion and the folks at Filemaker that work with that particular list of suggestions will see that more than one user likes the suggestion.

                         

                        Next stop, the Feature Request Form :smileysad:

                         

                        PS. Its Set Table Context not Set Table Contents :smileywink:

                        • 9. Re: onRecordLoad oddity
                          deltatango
                            

                          LOL, even though I also put table "contents" I had understood context! Guess I was also a bit sleepy this morning.

                           

                          And yes, I submitted that suggestion years ago and still no luck.

                           

                          grrr....

                           

                          >_< 

                          • 10. Re: onRecordLoad oddity
                            philmodjunk
                              

                            Well, now I've suggested it as well.

                             

                            You never know how a feature request willl be received by FM Inc.

                             

                            I can see features today, such as Manage | External Data Sources that were once requested by me or others many years ago. Whether it was my suggestion or someone else's, I couldn't say, but FM Inc. did finally incorporate them.