1 of 1 people found this helpful
The easiest way to solve this is to create a new record and insert some container data. That will create the correct folder structure relative to the runtime file. When that is done, copy the RC folders from the original location over to the runtime location.
Thanx for the hint. It triggered the resolution !
After I created a record I noticed that a directory "Files" is created, not a directory RC_Data_FMS.
Inspection revealed this 'Files' directory is also present in the backup directory of the original database (the dir I used to make the Runtime from) but two levels down :
In backup directory :
RC_Data_FMS -> DatabaseName - > Files -> DatabaseName -> Secure -> ......
In Runtime directory :
Files -> DatabaseName -> Secure -> .....
So as a test I created a fresh Runtime version and then also bluntly copied the "Files" subdir into the Runtime directory and then it immediately works !!!!
Very cumbersome but at least a work-around resolution.
I think FM should tidy this up and make sure external stored data is (or can be slected to) copied automatically.
When the data is embedded this is also the case. Do you have any clue where we can post this bug ?
TWIMC may have runaway content,
(Sorry, no signature means no name).
Can't do that. Remote container storage has to define a location on the hard drive to store that data. Moving the file to any other computer makes it impossible for FMP to know the new path. A run-time system will always be deployed to a different computer than where it was developed. That makes it impossible to set up in advance an external storage location that will work after deployment.
If you have 'container' content that is part of the runtime then you will have to store it within the file. After deployment you could have the contents automatically moved to external locations. But WHY? If the end user decides to move the files to a different computer you've just lost the contents, again.
I think that overlooks an important use case for runtimes: distribute a static database like a catalog, where users would not create new records but simply look things up.
Exactly right Wim.
My need is that I want to showcase the information in my database at places where I have no Internet access and hence no connection to the FM server. I can live with read-only access to the data. Typical useful in sales pitches,meetings etc. where 3G is poor and WiFi not existing.
For this the "Runtime standalone" creation function of Filemaker fits exactly my needs. Has helped me already quite a lot.
Indeed data embedded in the containers worked. But then 'external storage' came around the corner in FM12.
By creating "Runtime standalone" executable FM creates a single working dorectory in which the runtime libs, .fpur file versions and the Exece are placed. When copying to this directory the 'File" directory things work again. I tested copying this whole directory around which caused no troubles so you could easily put it on a USB stick and use it anywhere any place. No FM server connection needed.
I have done a runtime application that needs to pull down PowerPoint presentations. I put the files on the web using the RecordID as the variable in the file name. When the user goes to that record, if the container is empty, it is loaded from the web using the 'Get from Url' command and externally stored with the runtime solution. When the container is not empty it just runs the PowerPoint, and to do this I use Export Field Contents to itself with automatically open.
You can do this for movies as well of course.
You can update by clearing the container icon, then next time it downloads the latest version.
Very interesting alternative. Not for my "non internet" scenario but interesting read !
Will certainly use this mechanism in the future. Thanx for the hint.