Export Field Contents allows you to specify both the field and the repetition. You can use a variable and a loop to step through the repetitions:
Set Variable [$I ; Value $I + 1]
Set Variable [$Path ; Value: //put expression here to specify file path and file name]
Export Field Contents [YourContainerField[$I] ; $Path ]
Exit Loop IF [ $I = //put constant here that equals numbe of repetitions in your field
You might want to modify your design to eliminate the repeating fields also. A table of related recors with one non repeating container field per record is a much more flexible approach.
I take it then that doing the export of the repeating fields to a new table in the file, then showing related records from new table in the desired layouts is the best option?
How would you allow the user to enter multiple files once the repeating field is eliminated? Would you need a button that created a new record in the new table (with the ID# to make it related to the old table) then insert the file?
A little background might help explain what I am trying to do - The DB is for generating quotes for services. Requests usually come in via email and sometimes have attached documents (spec files, statements of work, etc) that can be almost any file type. Sometimes we create files that we attach to the outgoing quote as well. Our objective is to have the file attachments saved with the quote and be available to anyone that ends up working on the job. I originally thought that the repeating container was the way let the users insert those files. Since I started the project I have learned how to get filemaker to create folders based on calculations using field names and to export and insert as reference a container field so that the attachments do not make the DB get too huge. But am trying to decide what is the best way to change my DB to get the best performance and functionality. If I am getting what Phil is saying, There could be a relatively unlimited number of attachments for each Quote. There being how ever many records in the new table for attachments related to each quote in the old table. And with there being two types of attachments, incoming and outgoing, it would be best to set up a new table for each, since they is rarely ever the same number of each type for a quote.
When you have multiple child records such as these image records all linked to the same parent record (your quote). The simplest way to handle it is to set up a portal to the child records on a layout based on the parent table. If You enable "allow creation of records via this relationship" for the child table in this relationship. You can add new records in the child table just by entering data in a field in the bottom blank row of the portal.
Of course you can also use scripts to control this process also and you may want to use that approach to make sure that new images are all successfully stored in a common shared directory on the server that all workstations map/mount in exactly the same way so that your store by reference container field makes the store files available to all your users.
OK, so now I have the parent table quotes and two child tables, incoming and outgoing attachments. Each child table has two fields a text field (quoteID) and a container field for the file. I did imports for both child tables from the parent table with the separate repetitions into different records. I made a test layout, with the repeating fields from the old layout and with portals showing related records from the child tables based on the quoteID matching. So far they seem to match up. After I checked the allow creation of new records via relationship, I get a blank record at the bottom of each portal where it will let me click on and insert a file.
Now if I set a script trigger on field modification (the script to export the container to $filepath, then insert the file as a reference), would that work for each child record as it is created by inserting the file?
To modify which field? I think I'd just place a button labeld "insert file" in the portal row so that users can insert a file into that portal row. The buttons script can then make sure that the inserted file is placed in the correct location, then inserted back into the field as a "by reference" file.
Why is QuoteID a text field? A number field linked to a an auto-entered serial number field in your Quote table might be a better option.
Sorry, yes QuoteID is a number field in all 3 tables, with the parent being an auto-entered serial number.
I was thinking of putting a button to insert the files, but I assume that someone/sometime will try to insert files on their own by right clicking on the container. So I thought maybe if I triggered the script when that container field was modified (went from being empty to having a file in it) that would cover that base.
You can set the container field's behavior in the inspector so that users cannot directly insert an image without using the button.
I'm not sure if the "insert" actions will trip that script trigger or not and as you have more than one option for inserting the file, a script fired by it would have to be intelligent enough to handle Insert Picture, Insert File, Insert Object (windows only option) correctly and also to handle both direct and by reference versions of these inserts. I think the button option will be easier to implement.
I think the script is triggered by the value in the container changing, so that it would not matter whether it was insert picture, insert file or insert object. I have been playing around with it and it triggers whenever any kind of file is inserted and even if the file is deleted from the container.
Unfortunately the script I am using is now giving me a "File:whatever.pdf cannot be created on this disk" Earliler this week I was using the script manually to test it out and it seemed to be working fine. I could watch in finder as it created a folder and exported a pdf into the new folder. No sure what changed between then and now.
The different insert options insert data into the container field with different formats and Insert Object does not insert any data at all that you can access via the script. Thus, your script may work for one insert option, but not for others unless you include code to analyze the data inserted into the container field--that's doable for all but inserted objects and even that action is at least detectable--but all looks to me like a needless complication for you to have to figure out and handle when you can use a button that walks the user through process that is exactly the same for each new image to insert.
Your error message probably indicates that your script has produced an invalid file path and this can happen easily due to the different ways you can insert into a container field.
The issue I was having was that if the file was inserted as a reference, my $filename = GetValue(container; 1) would give me file:filename
I got the correct $filename if the file was not inserted as reference. I fixed that portion by using $filename=Substitute (GetValue(container;1)file:, "") which will return the correct file name regardless of how it is inserted.
My main problem with using the button to force users to follow the insert file path is that some of our users are "old and stubborn" and will insist on being able to right click to insert it anyway.
The script, as I have it now, will create a folder on the server for a customer if one doesn't already exist, export the file in the container field to that folder then insert the file from the server as a reference. It seems to work fine for all file types (except for insert object), images, pdfs, docs, xls, and txt.
There was an error message that came up if a file was deleted from the container, "cannot export container". that I bypassed with a "IsEmpty" check on the container that exits the script. That instance should not happen unless someone inserts a file accidently and deletes it before replacing it with another.
How are you creating a new folder?
I don't know of any way to do that with just a plain FileMaker script. It usually requires either a system script or a plug in as far as I know.
I'm using the perform applescript to run a "mkdir -p server/quotes/" step that creates the folder based on a calculated field, quotes::foldername which is "attachments/" & Quotes:customer
Then I use that Quotes:foldername to set my $filepath for exporting, inserting and opening the files as I need.
I figured it was something like that...
had an idea....... there are a couple of users on Windows........what if I did ......
If get(systemplatform) = "windows"
setfield windows flag to "1"
Then on a mac machine that did a find for windowsflag = "1"
went through the find results, created folders and export/import the files then cleared the flag