6 Replies Latest reply on Jun 13, 2013 6:07 PM by RickWhitelaw

    Unstored calculation

    SteveKeiser

      Title

      Unstored calculation

      Post

           I am using a FM database to manage items on a webstore. In the past, I have created calculations to determine the new price,  then pointed the price field to the newly calculated field to copy the new values over, then changed the price field back to a number field. The problem I have with my new calculation, is that it uses a value from a global field. Now I find I cannot retain the values in the price field when I change it back from a calculation. Can anyone suggest a workaround?

        • 1. Re: Unstored calculation
          RickWhitelaw

               The fact that you have to change your calc field back to a number field indicates a design problem. When designing your database try to imagine yourself as a user without access to the design elements necessary to change a field type. Why not leave the field as a calculation field?

          • 2. Re: Unstored calculation
            SteveKeiser

                 This is a database that no one else uses.

            • 3. Re: Unstored calculation
              philmodjunk

                   What our OP describes here is a trick that forces auto-entered calculation field to update to compute new values after the calculation expression has been edited.

                   Why does this field need to be an auto-entered calculation? Why not leave it as a calculation field?

                   Hopefully, this is not a calcualtion that computes prices in an invoice or this kind of update of existing records is almost always something you don't want to have happen anyway.

              • 4. Re: Unstored calculation
                schamblee

                     You shouldn't have to change a field type and is not good design practice.  For example a better method would be to have a number price field and then a priceCalculation field, then create a button to set field [price;priceCalculation].   You may be able to use a script tigger, but I don't know enough about your app to suggest method to do that.

                • 5. Re: Unstored calculation
                  SteveKeiser

                       The database is used only to manage a database that drives the webstore. The webstore database user interface does not allow the kind of complex calculations that I can do in Filemaker. Consequently I export the webstore database, manipulate it in Filemaker, then export from Filemaker back into the webstore database. What I do is analogous to creating a calculation column in Excel to compute values, then copy only those values back to the column used in the calculation. That is what I have been doing in Filemaker. The reason I use Filemaker, is that the field names are impossible to remember with so many. I also cannot remember what the various "1"s and "0"s mean. In Filemaker I use tooltips to remind me of the needed settings.

                  • 6. Re: Unstored calculation
                    RickWhitelaw

                         Steve,

                          

                         Understood. But rather than going back under the hood to change a field type you should keep your field as a calculation and add a number field whose value can be set using SetField based on your calc field which, I believe, has already been suggested.My comment about imagining yourself as a user applies. What you want to do can be done without "going under the hood" each time an update is needed.