Can SC directly access an existing file instead of using it's own directory system?

[BrentHedden]

My company has an established file system on a SAN where all of the client files are stored. We want to use SuperContainer to provide an easier way to open/view said files inside of FileMaker, especially with FMGo.

We do not use container fields in the FileMaker solution, but rather store the full path name in a text field(s), and then have a button that uses the Open URL step that points to the appropriate text field to open said files.

We're wanting to now replace this functionality with SuperContainer for several reasons, mainly being able to have a preview of the file and for ease when using FMGo. We don't want to change/convert the current file system we have setup, and it appears that using SC would force us to have two copies of each file.

Is there a way to have SC directly reference a file instead of using the folder structure that it natively uses? I realize that I can change the default folder location (with the web.xml file), but I'm wanting to reference an already existing file without having to copy it to the 'supercontainer' folder structure.

As an alternate, I've been able to use the SCSetContainer function call and set the 2nd (data) parameter with the direct location of the file, while copying it to the same SC location each time. In essence creating a temporary copy. Which works great, EXCEPT for FMGo, which can't use plugins ;(

If what I'm wanting to do isn't possible, I would certainly be willing to entertain any other ideas that you might have.

Thanks!

[ooparah]

Hey Brent,

Unfortunately, there is no 'easy' way to go about this and the approach you have taken has gotten most of the 'heavy lifting' out of the way. In order for this to work correctly (and with FileMaker Go), you will need to do the complete migration of your existing files to SuperContainer. You will need to first construct a script that will iterate through all of the existing files in the SAN and create a CALCulation that will construct the system paths for each of the files -- and place those files into SuperContainer. When the files are in SuperContainer, SC will create the file structure needed. Then, as you've mentioned, you will need to make changes to the directory that is being pointed to in the web.xml file to the correct SuperContainer files folder -- this change would be made under:

<param-name>windowsFilesPath</param-name>

Hope this helps,

[Smef]

Let me clarify this response a bit for you.

MIgrating to SuperContainer should be very easy for you to do using the Companion Plugin and the SCSetContainer field. You can call SCSetContianer in a looping script and pass in the URL you are using in you Open URL script step as the data path to upload all of your files to SuperContainer quickly and easily. You would not need to keep your old copy of your data as you would now be accessing your files through SuperContainer.

Is there a particular reason you would need to maintain the old file structure of your data? Once you have moved it to SuperContainer you would not need the old location to access in either FileMaker Pro or FM Go.

[BrentHedden]

Thanks both of you for the responses.

I understand the migration process that you outlined. It's nice to see how easy it would be to do so, especially in comparison with other migration projects I've dealt with.

Our company needs to keep the file structure the way it is to ensure that someone who isn't in the FM system can still access/consume the file(s). The directory structure is defined in such a way that it's very easy to find either an exact file or a group of related files. This kind of structure can't be emulated (easily) using the SuperContainer method.

After setting this up, I remembered that the directories/files that I need to access are only available to domain users. Which works great for desktops, but no go for FMGo users. So my original request wouldn't be useful anyway for me even if it was possible

I decided to go with a hybrid plan - for FMGo users, SuperContainer will only be used for certain documents, and those ones will have two copies available - one under the SC structure. Old files will be purged after a while, to keep maintenance possible and to avoid having too many duplicates available.

Thankfully we have a resource available such as SuperContainer, otherwise FMGO users would simply be out of luck.