Is there a way to copy the contents of a container file (in my case a file) to another container field by script?
The solution I am using came from Kevin Frank (FilemakerHacks.com). To answer your question, I am exporting the contents of the container to the Filemaker Temp directory and then importing the file back to the container where I need it. I am doing this via a script.
Couple of things to mention;
1.) I am doing this at the local level (FileMaker installed on the machine making modifications), this will work in a networked solutions, but I do not think this will work with web direct.
2.) I have not tested this with very large files.If this is used in a network environment, I believe FileMaker will have to download the file, and then upload the file to the new container- all which may impact performance.
FYI - The Filemaker Temp directory is created (and deleted) each time the Filemaker application is opened or closed and is local. This takes care of the housekeeping issue of cleaning up the temp files.
To determine the path to the temp file, in data viewer, select the watch tab and add the value; Get ( TemporaryPath ). This will display the file path.
Why not just insert the file into another container field and remove from the original field?
The container fields are both in the same file, different tables. The insert command appears to be looking for a file path.
Use Set Variable and Set Field, or simply Copy and Paste - the latter is usually recommened against, but if you do it consciously ...
If the fields are in separate table in the same file you should be able to transfer the container contents using SetField in a script, or maybe even an auto enter calc. You will to devise a means to transfer between the right records. This could be a relationship between the two table, or a script that enables you to step through one record at a time and select the FROM and TO sides as you go, or … The best approach will depend on more information than you have supplied, but hopefully you will be able to work it out.
I'm trying to do something similar and achieved this by setting up the field into which I need the copy to be a calculated field. The calculation is simply the name of the originating field.
What I want to do is have one field to keep a reference only and the other field to store the file.
The idea is that the referenced file allows users to edit the file as they wish and it's saved to the our job data server.
The copied file is stored on Filemaker Server so that when I archive and remove the jobs from the job data server all the referenced files are still accessible.
I have tried:
1) Copy the referenced file and paste into the archive file field same table.
2) SetFile - source referenced file and target archive file field same table.
3) Copy the referenced file and paste into the archive file field separate related table.
2) SetFile - source referenced file and target archive file field separate related table.
Each time I move the referenced file the archive file field displays file not found message implying that it's copied the reference but not stored the file to the FM Server.
Any thoughts anyone? Thanks.
/just re-read your problem, perhaps make the destination field in the other table a lookup field?
Would not a lookup imply a "copy-in-time"? And that can be beneficial, but a container has file storage (local or remote), unless by reference. So how does lookup help (or not help)?
I'm just trying to get more thoughts from your answer.
ahhh yes, I'm just a Newbie and in trying to work out a solution for my own similar problem I looked at 'lookup ' and because his solution has the originating field in one table and the copy in another I thought it was just another way to skin the cat.
Not sure it really helps at all
And it may well be another way to skin the cat. There are advantages of the lookup. It was a good suggestion that may work for someone at some point.
To further the discussion, a 'context' is needed and if the two table are NOT related, then copy/paste would be an alternative (tho, not often a favorable one).
I guess part of the thought process is to know exactly why this kind of thing (another 'copy' of the container in another table) needs to be done whether by relationship or not.
Re: "I guess part of the thought process is to know exactly why this kind of thing (another 'copy' of the container in another table) needs to be done whether by relationship or not."
I agree. It seems to me that a better method would be to store the file (I'd recommend external secure storage option), then when users need to edit it, export it, edit and then reimport. The final step will overwrite the original, and if Temporary path is used, then you won't be left with unstirred copies of the file sitting around on your desktop(s).
Thanks for the response. In my case, I am working with training database where I have table which addresses training topics including PowerPoint files from which the topic is taught. The PowerPoint files over time are updated, using as you suggested, the export / import procedure. However, I have another table which tracks training classes and the topics instructed. I have a need to maintain a copy of what was actually used on the date and "copying" does not work. The solution I found to work was exporting to FileMaker's temp directory and then importing to the container field in the new record.
I just used the Set Variable and Set Field steps, they worked fine for a small file. We can't really be sure what FM is doing in the background, I think it handles references and doesn't actually allocate the container data in memory.
A simple programmatic way of doing that copy is using the free FMP JDBC driver and SQL.
Check out the FMP 16's JDBC programmer's reference.
Set Variable [ $c ; container ]Set Field [ container ; "" ]Commit RecordsSet Filed [ container ; $c ]
Set Variable [ $c ; container ]
Set Field [ container ; "" ]
Set Filed [ container ; $c ]
I lose container content. So you are correct, and FM is not fixed on count of reference yet now (tested on FM17).
Retrieving data ...