Try this: instead of using the automatically open option of the export field contents, use a separate "send event" script step to open the file.
You defnitely should not try to export to the temp folder: that one gets deleted as soon as the script is done so you bascially have the desktop or the user's documents folder you can play with. Or you have to add an additionl Send Event after the export to move the file top where you want it.
Thanks Wim, I will try opening as a separate process from the export first thing in the AM.
As for the temp folder, at least on my development machine, the exported file (to the FMP temp folder) persists after the script is done. I watch it outside of FMP while running the app. My understanding was that the temp folder gets cleared when the local client shuts down and this seems to be the case running the program as a local single user, no server. Haven't tried it yet on my client-server setup; will do that also and see if there is different behavior.
I found similar results when creating my own temp folder in the FMP root directory and using that for processing.
I have used the temp folder for similar setups. When I do, I use a unique name for each file I export/import. I can see where the file name might be an issue when you get to the second round of edits and you export the file with the same name as one that already exists in the temp folder. I'm not sure how it handles overwriting the existing file. So a possible workaround may be to append a time stamp to the UUID when you create the filename and store the current file name in a global field, or global variable or field. So when the user goes to import the updated file, you have the correct file name to import.
FileMaker should clear the temp folder when you close the program. Take a look at this KB article.
http://help.filemaker.com/app/answers/detail/a_id/6885 and as far as Client-Server set up goes, FileMaker will use the clients Temp folder the same way it does when you open a local FileMaker database.
Thanks Bruce. I agree. What I'm doing is creating the filename as a global var and append a "_x" to the end right before the extension where "x" equals the "version" number. On open/edit I check if the file is already there (the first time no so the global var is null and the version # = 1). My update scripts just use the global var as the path so it always has the latest version in it. If the file already exists I just increment my version number before I create the file path/name. Pretty simple and works fine. I'm going back to using the FMP temp folder so I don't have to worry about cluttering up the disk with a lot of files since as you state, the files are deleted on client side closing.
Wim, I tried not automatically opening and then sending an event to open the file. That works fine but does not resolve the problem so I went to what I'm doing above. If I do an Insert File, no matter what I do after that, the external function "file delete" fails so FMP must still have an in-use lock on the file. If I don't run Insert File I can delete the file easily.