AnsweredAssumed Answered

Container storage - Open and external naming problem

Question asked by ErichWetzel on Oct 31, 2016
Latest reply on Nov 4, 2016 by TSGal

Current systems:

FMS on a Mac OS 10.11.6 with a valid GoDaddy certificate of acceptable format to FMS.

FMP on macOS 10.12.1 clients bound to Open Directory on a Server running macOS 10.12 and Server 5.2


I was testing external storage for containers because a Documents.fmp12 store file is getting inconveniently large to back up. The backup is inconvenient in that, in order to back up the newest document added to the Documents.fmp12 file I must make a back up of the entire file which is now over 40GB.


My plan was to push all saved documents to open storage which would leave a fairly small Documents.fmp12 file. The file now backs up easily and I can run TimeMachine on the documents open storage which will back up only the newest documents added since the last backup. I kept the open storage because it would be on a server and not accessible by general users AND most importantly I could get back into the files manually to find documents if needed as long as my naming scheme permitted doing so. The idea was to set this up as a fall back against corrupted database files where the document linkages have been lost.


In trying to set this up. I found an odd behavior that does not make sense to me. I set up a Test database with three fields and one record:





The container field was set to open with the associated records being stored in a folder called: Name & Date


The odd behavior comes in when changing either of the field names that the folder name is based on. If the document storage location is based on the two fields, and one changed, I would expect the name of the document storage location to change to reflect the new values.


They don't.


If I put in Name::Tom Date::10-31-2016 and add a document, and realize that I meant to put in Date::10-31-2015. If I make the date change, the folder name does not change. But the database does still show the document in the now mis-named folder. The now mis-named folder is also potentially very difficult to find again under my plan because it would not be under the proper date.


Additionally, if I make the date change and then remove the attached document, and add a replacement document back in, it shows up in another folder under the new and correct date. The old mis-entered folder still exists in the filesystem. So depending upon how I set this up it seems that I could have huge numbers of empty folders around.


This gets more complicated if the documents are placed into a related table linked by a serial number but the naming scheme is the same. Let's say I am saving some documents in my record for Tom.


Let's say I have Name::tom Date::1-1-2014 and I put in a document. The attached document is saved in /tom1-1-2014

Let's say I changed to Date::1-1-2015 and added a new document which is saved in /tom1-1-2015

Let's say another user changes to Date::1-1-2016 and added a new document which is saved in /tom1-1-2016


For a single database record: I now have 3 differently named folders, all containing 1 document each, rather than the expected 1 folder, renamed with each data change, with 3 separate documents.


The database can still see all three of the documents but my effort to consolidate my documents just broke down and I cannot find them  manually because the three documents for tom are scattered all over the open storage folder, under names that I will not be able to reproduce because I cannot possibly know all of the errors typed into the records by the users over time.


In general database use, a change in a field results in changes in related tables, calculations, etc. Why not with documents in Open storage?




-Erich Wetzel