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.
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.
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.
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.
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.