5 Replies Latest reply on Dec 31, 2016 12:32 PM by bigtom

    Updating Container Fields


      We use a container field to store different employee's signatures to print on their different forms based on the employee assigned to a case.

      Then we have a calculation field that has a case statement to determine which signature to use based on the employee assigned to the case.

      However, we are running into an issue when an employee leaves and a new employee is assigned to the case, it will not change the signature. This issue is also happening if the user gets married and changes their name, the signature does not display at all. I need for these cases to update with the most recent signature.

      Is there a function within the containers setup that allows you to not store calculated results and recalculate when needed like it is setup on regular calculations?


      I did not build the database but I do plan to change the setup for the employees by creating their own table and such. However, I need a quick fix for now.

      Thank you in advance.

        • 1. Re: Updating Container Fields

          Sounds like you need signatures in a separate table joined the employee and then joined to the documents. If you already have this then a recalculation when a signature changes is needed.


          Depending on the situation you may need to keep and old signature attached to a document even if it is not a current one. You can use unstored calculations, but it might be wiser to have a script run the calculation and store the value you need at the time of use.


          For unstored, when you setup the field just select the setting in Storage tab to never store and always calculate value.

          • 2. Re: Updating Container Fields

            I don't think that you need any calculation at all here.


            With a table of employees--which you can extract from an existing table via import records using a unique value validation to get one record per employee--and thus this can be done fairly quickly.


            But with that table, you can link the signature by an employee ID field that is NOT their name nor derived from their name. If you assign a new person to that case record, you would select their ID via a value list or other value selection method (there are many options here) and the change in ID in the field of the case record then links to a new employee record and thus their signature field can be included with the Case record.


            I'm not a lawyer, but I'm concerned by what you want to do here as this system could easily be abused.

            • 3. Re: Updating Container Fields

              philmodjunk. OP says there is no employee table and seems to need an immediate "working fix" for a problem that does not require adding an employee table right away even though that is the desired end goal. In my opinion adding the employe table with another table of signatures should be done now and used along the lines of the manner you suggested.

              • 4. Re: Updating Container Fields

                I understand that there should be an employee table. I already mentioned that in my above discussion.

                This is only an internal database for our office (so it is not being sold or anything for legal issues) and the only reason an employee table was not utilized I am guessing is because we monitor case information and we just needed to know which employee was assigned to the case. No other information is used for employee except for their name. However, I plan to change this and it is my plan to have the new table with the signatures assigned based on employee number but I needed something for just today while I fix other issues that updating to Filemaker 15 has caused for supercontainer.


                I tried adding a calculation field with the case information, and returning a container value but that is not returning any signatures.

                • 5. Re: Updating Container Fields

                  Yes, but my immediate fix would be to generate that employee table using Import records to pull the needed data into unique records in the new table. This isn't as hard as it sounds in many cases though your mileage may vary of course as I can't see your current design.