1 2 Previous Next 19 Replies Latest reply on Feb 5, 2015 7:26 PM by njem

    external script

    njem

      I had a script fail to do as expected and I think I have it figured out but want to be sure so I do the right thing to avoid that in the future.

       

      This is a two file system. (If I had it to do over it would be one file.) I'll call them Front and Back. Front called a script in Back. The script in Back used Go To Layout to go to one of its own layouts (that is a layout in Back), did a find, again used Go To Layout to go to another layout in Back for a table instance with a relationship (likewise the relationship is in Back). Then did some mod of the data there. That failed. From debugging it appears when it got to the 2nd layout the found set was not just one matching record but all records. This relationship and the script work if I run it directly in Back. I worked around the problem by simply staying on the first layout and setting values in the related table by using SetField(Related_Table::Field, value).

       

      I'm assuming that what got me was I called a script in an external file which used layouts and relationships in that external file. Generally if I wanted to do this I would have created table instances in Front, and related them, and created a script in Front to work them. All of this just happen to already exist in Back so without thinking about it I just called the script in Back.

       

      I know Front can't rely on relationships in Back. But when the script is in Back and uses tables and relationships in Back it mostly works. It gets to that first layout, does the Find correctly, and when it sets data by Related_Table::Field it works. It's just that relying on the relationship when going from one layout to another failed. Am I on the right track here?

       

      Thanks,

      Tom


        • 1. Re: external script
          wimdecorte

          njem wrote:

           

           

           

          This is a two file system. (If I had it to do over it would be one file.)

           

          There are many reasons to NOT put everything in one file (risk, backup efficiency,...) so don't let a speedbump push you into making the wrong decision here.

          • 2. Re: external script
            wimdecorte

            njem wrote:

             

            I know Front can't rely on relationships in Back. But when the script is in Back and uses tables and relationships in Back it mostly works. It gets to that first layout, does the Find correctly, and when it sets data by Related_Table::Field it works. It's just that relying on the relationship when going from one layout to another failed. Am I on the right track here?

             

            I'm afraid you lost me with this paragraph.  On the right track for what?  Are you still talking about the hand-off to the second file?

             

            You can't use Go To Related across files so you want to use scripts and relationships in file B you have to give file B instructions on how to create the context (what table) and found set (what records) to act on.

            • 3. Re: external script
              mardikennedy
              I have a very similar Front/ Back situation and I've also had some... unexpected... results.  Very occasionally, a script which has behaved consistently and perfectly will cease to deliver the expected results - it gets 'stuck' with an earlier 'found set listing'.  The fail always occurs in the second file on a GTRR step.  You can watch it fail in the Data Viewer.  Rebooting does not necessarily fix the issue but if you go in and manually remove the contents from this global field (that's actually in the first file), the script behaves normally again, rewriting the global field contents each time the script is run.  I don't know what triggers this intermittent 'sticky data' thing.  (Or to look at it differently, what prevents future data being 'overwritten'.)  This occurred once last week (with a script that has not misbehaved since) and a day or two back with a different script.  In my case, both report scripts use a ListOf summary that gets set into the global via a variable.  In the data viewer, you can see the correct, new data being recorded in the global in the first file, but when the script in the second file attempts to GTRR using this data, it instead uses a data set from a previous enquiry.  (!!!No, nothing to do with globals being set prior to the files being hosted.)  It's bizarre - and very intermittent - behaviour.  If I have the misfortune to experience it again, I'll try to document it better.  Does it sound at all familiar?  Regards, Mardi
              • 4. Re: external script
                njem

                wimdecorte, I mean am I on the right track understanding that I can count on a script in an external file using its own tables and relationships to work as described in my workaround (stick to layout 1, change data in related fields from that layout) and that I can't count on going to a related layout and have it have the one right record? Note I'm not doing this with GTRR but with Go To Layout, not that it should make any difference.

                • 5. Re: external script
                  njem

                  mardikennedy, yes, very similar. I've seen this scenario where it fails and on another try works. I suspect it's because in debugging I've gone to the layout in question, done a manual Find to check data, and inadvertently helped it work, but not in a reliable way. That's part of the reason I want to make sure I understand the limitations and don't count on things to work that shouldn't be counted on.

                  • 6. Re: external script
                    keywords

                    I assume the layout you want to go use is some sort of working layout, not a user interface layout. It seems to me you could deal with the issue by creating the working layout in the Front file, accessing fields from the Back file via the relationships between them—that is the essence of the separation model as I understand it.

                    • 7. Re: external script
                      Markus Schneider

                      We have many solutions with a couple of files. As Wim mentioned, there are several reasons for more-files (i.e. more than one developer is working, etc). In general, we create as much files as necessary, as less as possible..

                       

                      That's definitly NOT the issue.

                       

                      DO You have a 'new window' script step somewhere (the caller script could land in the wrong window)?

                      COuld it be an issue with the relationship (i.e. relationship with addressNr AND a date that isn't set)?

                       

                      YOu can (for testing) send the ID's and other relevant parameters via script parameter to the target file and do a search in the target file, add a scriptstepp 'activate window' or similar (don't have an english system here) to get a better view what happens

                       

                      (btw. on iOS, the caps won't go away, therefore the two caps letters)

                      • 8. Re: external script
                        wimdecorte

                        keywords wrote:

                         

                        accessing fields from the Back file via the relationships between them—that is the essence of the separation model as I understand it.

                         

                        It is, in the data separation model all of your layouts and scripts are in the UI file, you never make the data file do anything, it just stores the data, no logic or UI.  So under the data separation you would never take a trip to the data file to run scripts or visit layouts.

                        • 9. Re: external script
                          mardikennedy

                          I'm actually using a variant model - it's more 'UI separation' rather than data separation.  The data entry and that part of the UI is in the 'front file', and all the reporting is in the 'back file'.  The reason I selected this model is that many of the users (niche vertical) prefer to personalise the reports.  Thus, Finds are performed in the first file and recorded (via ListOf) and the second file then refers to the found set.  The second file has a very stripped back relationship graph but in some cases, a GTRR is appropriate.  (as I write this, I wonder about doing it differently... tangent tho'!)  What's bizarre is the intermittent (very rare) fails, using precisely the same script(s).  It's literally 'sticky data' for an unknown reason.

                          • 10. Re: external script
                            colins

                            I was reading your problem and something chimed in the back of my head, that may or may not make a difference. When I first moved from FMP 9 to FMP 12 I had loads of errors with scripts pretty much as you describe. I fixed each of them by adding a "commit records/requests" line (skip data entry validation/perform without dialog) at every point where the script threw up an error.

                             

                            No harm in giving it a try.

                            • 11. Re: external script
                              wimdecorte

                              No harm for troubleshooting.  But commits can be expensive too in that it may generate more traffic between server and client than is strictly necessary.  An overall check of the design may be in order to make things work as expected without any performance issues.

                              • 12. Re: external script
                                colins

                                windecorte, I absolutely agree. However, when FMP12 arrived no-one in Filemaker could explain the behaviour I was experiencing with my inter-file scripts. But then again, this wouldn't be the first time that a new version of Filemaker had completely messed with my scripts. Or my website. Or anything else I might care to mention. I left that "commit records" in place and my server runs happily without any undue load issues, but more to the point, it solved the issue - longterm. And no other action I could come up with did. I'm no novice, having been doing this for 17 years, so it's not as though I started clueless and stumbled upon this by chance. Sometimes, there is no solution to the kind of behaviour described. It can be as simple as an unforeseen Filemaker issue.

                                • 13. Re: external script
                                  Malcolm
                                  With this exception: when you need to operate on data with a raised security level that must be done in the file that contains the data.
                                  • 14. Re: external script
                                    mardikennedy
                                    On one hand, it's tempting to discount the Commit() option because in this case, it's Finds only.  On the other hand, it's an intermittent issue that resists 'logic'. I'm going to wait until (if) I experience it again, and if I do, I will then add a (redundant) Commit step to see if it has any effect.
                                    1 2 Previous Next