How can I find the path to an externally stored file

I moved my container contents to an externally stored file on the server. I want to refer to the file in scripts and load a local, temporary app copy on my computer. How can I determine what the exact path is?

Set the export file path and file name to a variable and just enter the variable name in the 'export field content' dialog.

That's what I did and why, I believe, it works when the files are stored internally. The question is why does it fail when I transfer (via FM) the files to external storage?

WAIT!

It just occurred to me that the TEMP local files are still there after I switch to external storage. FM won't report that the same-named file already exists; it just says it cannot create the new file.

THAT'S it. I closed FM to delete the TEMP local files and now when I relaunch and try to export/view the externally stored files, the script works.

Externally stored (or RC) data should be referenced like regular containers, not by pointing to the actual file on the hard drive. RC data files are just like ordinary live FM files: nothing and nobody should touch them except FM.

I started with internally stored content (embedded?) and it worked well. Then I changed the field properties so content was stored externally. FM took some time to transfer them all but said there were no errors.

Well we already knew from the error message that the file isn’t being exported so it isn’t going to be in that folder. The thing is that the error message doesn’t show a filename. Might be useful to step through the script in the debugger while monitoring both $variable, container, plus checking for any additional error codes.

Looks like you are doing something wrong in how you set the export file path. Very likely you're treating the dialog of the 'export field contents' as if it were a calc window. It is not. Set the export file path and file name to a variable and just enter the variable name in the 'export field content' dialog.

Set the export file path and file name to a variable and just enter the variable name in the 'export field content' dialog.

That's what I did and why, I believe, it works when the files are stored internally. The question is why does it fail when I transfer (via FM) the files to external storage?

WAIT!

It just occurred to me that the TEMP local files are still there after I switch to external storage. FM won't report that the same-named file already exists; it just says it cannot create the new file.

THAT'S it. I closed FM to delete the TEMP local files and now when I relaunch and try to export/view the externally stored files, the script works.

And after all this with repeating fields, I'm staying away from them given the recent discussion in FM Community included in the last digest I received. I know future developers may not "get" repeating fields nor have any use for them; I moving that data to its own table. What I learned about TEMP files and FM still applies though.

Something still isn’t right. Files should not persist in the temporary folder and thus it should not be possible to use them as a storage location in the past. And export field contents should be able to overwrite an existing file provided it is not open Plus, the original error message would have reported the filename, not “?” Had this been the reason.

I've seen a couple of error messages, depending on the script variables I changed.

"? . . ." was one.

[file name].pdf could not be created. . ." was another, and it's the one I see now if I try to open multiple copies of the container's pdf.

I also see what you say: FM will open up to two copies of the pdf from the container before reporting it cannot open it (again). If I close the pdfs in the pdf viewer, FM will happily open it again. I put a dialogue pop-up in the script explaining this if a user tries to open multiple copies.

Uh . . . you were right. I started getting "file '?'" again once I had all the references correct. (It looked like it was working before because I had the script referring to a script-test field that was stored locally. Duh.)

Now . . . I did finally work my way into a script and path that do work with externally stored container contents:

Line 7. I set a global counter and included it in the path name so attempting to open a duplicate pdf cannot happen. (The counter will also tell me if anyone ever even uses the button/script to view a file from the container.)

Lines 10-13. Now superfluous since the IF can never occur.

Bottom line:

When the file is stored locally I have no problem attaching the pdf name of the container contents to the TEMP file pdf name via the $FMPpdf (rather than use steps 3-8 above), but it fails when the file is stored externally; I get the file "?" not found error.

It does do it though. The new file in the temp path has a new name because of the advancing counter, line 6. I can open an unlimited # of copies, each with a different count# in the title. The name of each file is "temp[MemberID].pdf, count#[whatever# the counter is up to].pdf"

(I see now I have a superfluous ".pdf" midstream, but I'm not going to touch it. Ha.)

Here's the file open in the pdf viewer I use. Next to it is a copy of the same file with count at "#2."

That file name is bound to give trouble. I would change it and stick to only safe characters (a-z, A-Z, 0-9 and the underscore and dash) and have only one thing in there that can be construed as an extension, not two.

I also just learned/saw that the counter, a global field, resets after each user-session so I made an additional field that won't reset but instead keep a running count of uses. I'm curious about that.

(Knowing the globals reset is useful; it's actually a good thing for most of my purposes)

When a file is hosted, a global field's value is session specific. This allows a global field to contain different values for different users simultaneously. If you need it to be always primed with a specific value at the start of a user's session you need to run a script to achieve this.

Not if the file name is the same, the location is the same and the file is open. Then NO other file of that precise name can be created in the same exact folder. It will throw an error every time.

More on your file name calculation:

Set Variable [ $FMPpdf; Value:"file:" &

Get(TemporaryPath) &

"temp" & ----> no harm, but don't see any reason for this.

Container Misc Contents::MemberID & ---> This use of the container field returns file name with the extension.

".pdf" & --->5 and 8 are the same. why put "PDF' here? This gives you ".pdf" 3 times in 4, 5 and 8.

", count#" & --> This also seems unnecessary

Container Misc Contents::GFTemp counter &

".pdf" ]

The fact that the temp counter resets isn't really a problem here if you are closing the files after each session. The fact that each user gets their own copy of the value is also not a problem as each user has their own temporary folder on their own machine.

But this could be done simpler and, as has already been pointed out, should be filtered to remove problem characters from the file name.

If you are keeping multiple files open in the temporary folder, you might use this expression: