3 Replies Latest reply on Dec 8, 2011 4:34 PM by philmodjunk

    Insert Calculated Result Script step points at wrong field.



      Insert Calculated Result Script step points at wrong field.


      FileMaker Pro



      Operating system version

      OSX 10.6.8

      Description of the issue

      I have run into this since I started using FM11. This is the specific expample, but I have the same issue with the Button definition as well from time to time.

      Insert Calculated Result [Select; RS_Inventory::INV_Item_On_Hand ; RS_Inventory::INV_Item_On_Hand + RS_Inventory::INV_Temp_holder]

      The script step has worked fine for years. Suddenly it will start placing the Calc result in the Item Name instead on On Hand.
      If I delete the field from the Layout, it will place the result in the UPC field.

      And it replaces all instances with whatever field it is using at the time (adds Temp Holder to itself)

      It actually messes up all opened versions as well (shared over network).

      Steps to reproduce the problem

      Have not been able to reproduce the glitch, it just will show up from time to time.


      The only fix that gets results is to delete all fields on the Layout and replace all of them. Replacing the Script step will not fix the issue.

      This works until it glitches again weeks or years later.

        • 1. Re: Insert Calculated Result Script step points at wrong field.

          I never used this instruction script. I think it is very old.

          I suggest to use “set field” script instruction: it does the same and, moreover, it works even if the target field is not in the layout.


          • 2. Re: Insert Calculated Result Script step points at wrong field.

            It is 4 places under the set field script instruction in the "Fields" script instructions.

            • 3. Re: Insert Calculated Result Script step points at wrong field.

              Yep it's there, there's just seldom a need to use it anymore as Set Field is more robust. The one time it can be useful is when you don't specify the target field (or the specific insertion point within the text of the field) for a script designed to insert data into whatever field currently has the cursor in it at the time the script executes.

              Please note this doesn't explain why it would mysteriously put the data in the wrong field. That's nothing I've seen before. Not putting the data in any field, that's a known limitation that can trip people up when a layout gets modified and the target field is removed from the layout that's current at the time the script is performed.

              Since that's not the case here, a little extra sleuthing may help narrow this down:

              Does this only happen in one file (or copies derived from the same file)?

              Does it only happen on specific layouts?

              If you run a recover on this file is anything reported?

              I realize that the first two questions may be nearly impossible to answer, but if you can spot any additional clue here, it may help.

              Things to keep in mind about Recover:

              1. Recover does not detect all problems
              2. Recover doesn't always fix all problems correctly
              3. Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.