I can only guess that it has to do with folder permissions.
You might experiment (troubleshoot) by trying the Desktop or Documents path.
(This is Windows, yes?)
See Get(DesktopPath) and Get(DocumentsPath)
It's installed under full admin account on the server, I'm logged in on an account with full access to the machine. This is also a secondary storage drive where all the data is kept and there have been no issues creating directories and files on it.
If you use the FM default settings you should not have a problem. You shouldn't be accessing stored container data externally to FM anyway, so there is no real reason to set you own path.
What? That's not at all true.
Here's the scenario so maybe you can understand better.
We have our database which holds certain files that are 100% consistent that all clients need to have these files.
Then we have our file server, which stores even more documents that some clients may need and some may not need, it's random and depends on a lot of different things.
What we do is create containers for the 100% required documents, so that validation and requirements for these documents can be checked. We have a button that links to the external folder where these files are held so that a file structure can be in place to organize these documents.
For instance, Client A with a primary key 1234 has the required documents and a few more. Well we store the documents like so:
In this directory, the desired outcome would be all container fields store into the documents folder above, and when the user uses the filemaker solution to access this folder they can quickly drop in other supporting documents. Why in the world would I not want this to be available? I understand if someone deletes the files on disk then it can't be accessed from the container field, but this isn't an issue for us.
Yep, I've got it setup fine. The path validates just fine and has the filewin prefix on it. The server accepted the container location just fine - it's just not storing the actual data from the hosted solution into the folder I want it to.
1 of 1 people found this helpful
The point I was making is that you should access stored container files via Filemaker, not by direct access to the stored file. Access can easily enough be set up through the database—by exporting, then reimporting for example.
If you want users to be able to access the stored files otherwise, you would be better to just store a reference within your FM database. Alternatively, you can specify an external storage path or external storage, but you will need to ensure permissions are in place, as already pointed out by others.
2 of 2 people found this helpful
can you send a screenshot of the admin console page where the additional db folders and additional RC folders are set up and selected?
To keywords point: do not let the users touch, view, add, delete files to that D:\Data\Clients\1234\Documents\ folder. FMI has warned consistently that 'remote containers' is not a document management feature. It is there to let FM *internally* be efficient at storing and backing up container data. It is not meant to give users access to those documents outside of FM. RC data should be treated like you would treat a live fmp file.
If you want document management then build it ask keywords mentions or go with a product like 360Works SuperContainer.
To strongly support Keywords here. If you start accessing the folder directly you WILL corrupt the link between FileMaker and the stored files.
You can use use the additional container folders within FMSAdmin, add sub directories from within File:Manage Containers to set a base directory and then use a calculation within the container field Storage options when selecting external open storage, for instance setting folders by year and date using Year ( Get ( CurrentHostTimeStamp ) ) & "/" & Month ( Get ( CurrentHostTimeStamp ) ) & "/" will organize your files in folders by year and month within these. You could also use other data from within your tables to organize other ways.
Whatever you do, do NOT allow access to the RC_Data folder!
Read this in haste, also to support Wim earlier in the thread.
We have carried out detailed tests on behalf of other customers and just opening a file outside of FileMaker can make that file unavailable to FileMaker.
As suggested, do the organization from within FileMaker and introduce that into your workflow.
I think you're all missing my point.
The files contained in FM container fields will be and are already accessed through FM.
What I want to do is have them store in the same share as our Clients share as well.
Maybe I'm not expressing it clearly, but the real issue is the scenario below.
Client A, with an ID of 1234 has documents in container fields in the Clients table. These are currently stored externally via FM open storage so they don't bloat the database. This works fine, no problem there.
Client A also has a folder on our Clients network share that has all other supporting documents. The problem is that opening this folder only has those supporting documents and doesn't have the other documents which are accessed through the container fields.
How can I take both the documents in the share and the documents accessed in the FM solution into one Share?
Do I need to have a script trigger on the container field that also exports the contents to the share, or is there a better way to do this? The end result should be the user only needs to go to one place to view ALL documents on a Client. It's a much better user experience than having to go into FM to view some files and go into the network drive to view others.
Hopefully that is clear enough.
You can see the folders are setup just fine and are accepted by the server here. Now when I try to tell a hosted file to store the container data external to the container path D:/Data/ I can't seem to get it to do that. It insists on storing in the database location at D:/Databases/Main/ which isn't what I wanted. I would like to keep these two directories separate so that it's more organized on the server.
First, it seems to me we re not missing the point at all—you seem to want users to have external access to the stored container files: "The end result should be the user only needs to go to one place to view ALL documents on a Client."
Second, re: "It's a much better user experience than having to go into FM to view some files and go into the network drive to view others."—another way to achieve this would be to access ALL files via FM. Why not consider having the "other supporting documents" also stored inside FM?
We don't want all those documents going through FM. It's great for the required documents, because it can be validated before a Client's status is changed to "Completed" that all those documents are there.
For the other documents? Sometimes hundreds of photos of a Client's project are inserted at once. This would be a pain to go through FM because you have two options:
1. Zip the photos up, then insert the zipped file into a container. Needed to unzip every single time you want to view a single photo.
2. Upload one photo at a time into FM containers through a document management system built out.
We don't want either of those options. We like the drag & drop support of multiple files being uploaded onto the network share and available for anyone to view.
We do want to use the containers that exist to validate the 100% required documents before completion of a Client project, so that's why we use containers for the few documents that are usually PDF's that can just drag & drop easily into a container. In the other case with 100s of photos, that wouldn't be a good user experience at all compared to just dropping a folder of pics from your laptop onto a network share.
If I could also include a copy of those documents in the container fields inside of the network share, then it would be an even better experience for the end user viewing documents through the server very quickly without the need of going through FM for one document and through the share for another.