4 Replies Latest reply on Jun 3, 2015 2:30 PM by anchorbuoy

    Is there any way to perform a script when a related record is accessed?

    anchorbuoy

      I would like to put the script in the file which contains the related records because the user interface is scattered across dozens of other FileMaker files, and I'm trying to avoid putting a calling script in each layout that uses the related data.

       

      The script checks to see if a container field is populated, and if it is not populated, the script then uses Insert from URL to pull the file down from a web service.

        • 1. Re: Is there any way to perform a script when a related record is accessed?
          erolst

          As I understand it: if you access the record/field as related data, then by definition this event does not occur in the field's native file, but in the “layout file”, and the “native” one is none the wiser; so there goes your idea … (Of course, I may be overlooking something …)

           

          But regarding this from a distance:

           

          1. Why many files?

           

          2. If for some reason you must have many files, you could still consolidate the layouts in a single file; programmatically, it doesn't make a difference whether the layout's TO comes from a table in the native file or a file defined as an External Data Source …

           

          3. If that isn't possible (or simply entails too much effort in an “organically grown” solution), maybe try to limit access to that field.

          • 2. Re: Is there any way to perform a script when a related record is accessed?
            anchorbuoy

            Many thanks to Charles Delf, from Delfs' Engineering, and Hal Gumbert of CampSoftware for discussion on https://fmpeeps.slack.com/archives/techsupport/p1433349373000063.  One idea that came from the conversation was using an unstored calc and a plugin that allows you to call a script from within the calculation engine (such as DoScript or SmartPill PHP). I have yet to test this, but it is the direction I will be exploring next.

             

            To answer your questions, erolst:

             

            1. Why many files?

             

            Because they correspond to the many different applications we sell. (I work for http://www.inresonance.com, and all our core applications are built in FileMaker but installed separately). Each application is made of multiple component files, as well.

             

            2. If for some reason you must have many files, you could still consolidate the layouts in a single file; programmatically, it doesn't make a difference whether the layout's TO comes from a table in the native file or a file defined as an External Data Source …

             

            That is an option for some functions (where clicking the "View" button, for instance, opens up a layout from the shared file), but not in all circumstances. Many of these solutions already have relationships and portals (or other things) set up that depend on the relationship.

             

            3. If that isn't possible (or simply entails too much effort in an “organically grown” solution), maybe try to limit access to that field.

             

            Unfortunately, that's not an option. The field is part of a central file management system -- the various solutions share the same file storage database. Limiting access would be counter-productive in this case.

            • 3. Re: Is there any way to perform a script when a related record is accessed?
              erolst

              Good to see that you were able to give yourself such a great answer.

               

              But then, why don't you post the actual link to that discussion? It may be of interest to others.

              • 4. Re: Is there any way to perform a script when a related record is accessed?
                anchorbuoy

                I did post the link -- it was on fmpeeps.slack.com. Recently learned that I can get archive links, though, so updated the answer with a more direct link: https://fmpeeps.slack.com/archives/techsupport/p1433349373000063

                 

                And although my name's on the forum post, the answer really came from the two guys I mentioned at the top -- Charles Delf, from Delfs' Engineering, and Hal Gumbert of CampSoftware