Assume that we add thousands of documents per year into our Documents database and that we back up our database every day. Each day the entire database and all documents in it are duplicated to the backup. During down time overnight, the backup itself is moved to another backup location, in another building, across a LAN. Every backup duplicates every document, every time. This method takes a couple of hours to move the Documents database each night which seems to be a poor use of bandwidth and storage.
If our system was changed to external storage of container content we could back it up in a methodology using Apple's TimeMachine, where a single backup is made of files and the TimeMachine system knows where each file is rather than backing up every file multiple times. If we were to go to this method, only the newest document files would be moved to the backup, taking not more than a few minutes to backup the entire Documents database and its related content.
Assume we have total control over all backups, backup locations, and that any further need to obscure what is stored at the OS level is irrelevant. I am not looking to start a debate over security. For our own reasons, we want to have the ability to recover our related documents in the event of catastrophic database failure. The current difficulty is that unless the fields used to generate a calculated OS folder name for storage never change after the first document is added, the documents themselves can wind up difficult to find by OS folder name search later. More directly, if the data in the fields used to create the OS folder do change you wind up with documents related to a single record in multiple folders with several different OS names.
So the feature request is to allow for calculated OS folder names to CHANGE if the data in the fields used to generate the OS folder name changes the same way that calculation fields update with changes in the source fields.
The following fields are the ones we wish to use to generate an OS folder name to store the related documents. Due to the relational abilities of the databases themselves, changes in these fields do not have an impact on the ability to find the related documents.
Use these to create an OS folder called:
So far so good. Add a couple of documents for Tom and they all end up in the folder.
Someone later realizes that his name is actually Thomas and now we have:
Despite the fact that we have new documents for the SAME person, the updated data is used to create a NEW OS folder called:
Add a couple of documents for Tom and they end up in the NEW folder.
Now we discover that Tom's date of birth is actually 1-2-1929 and now we have:
Despite the fact that we have new documents for the SAME person, the updated data is used to create another NEW OS folder called:
Add a couple of documents for Tom and they end up in this THIRD NEW folder.
FileMaker has managed to keep track of all of this and can see all of the related documents.
Now we have a catastrophic database failure and I want to find our documents for Tom by hand in the OS while the database is down. I made the fortunate decision to stop saving documents inside a database and should be able to still get them manually from the OS level storage. I will not be aware of the changes being made to the database over time by the various users or that there are 3 SEPARATE folders for documents related to the same person / database record. I use an OS level search for the name of the folder. If I use Tom I get one result, if I use Thomas I get a second result, if I use his date of birth 1-2-1929 I get a third result and none of them are actually correct. I did, however, get the side benefit of backing up only the newest related files each night rather than backing up ALL of them each night. Unfortunately I cannot find them when I need them.
So if FileMaker were to change the OS folder name if the data in the fields used to create the folder name changed... In the scenario above, EVERY document for Tom would at least be in the same folder and once I found it I could be confident that I had ALL of the documents for Tom.
Using a serial number or other unknown, but unchanging, piece of information does not help because I would not know the numbers to search for, or I would have to regularly print a list, and protect that, and make copies, and store them, etc. I on the other hand do, or someone related to Tom does, know his name and his dates because they are relevant pieces of information that never change about Tom. However, we are trying to accommodate flexibility in our KNOWLEDGE of the unchanging information.
Thanks for your consideration.