Is it possible that a user might use Insert Picture with "store a reference" specified to put the file into incoming::incoming?
if that method is used, your first script step won't extract the file name as that won't be the first line of text returned from the container field.
If that isn't it, I'd set up some method to check the values of each field and variable used to specify the file name and file path to see if any of the values are not what you expected to see here. You might add steps that copy these values to global variables and use either the data viewer or a script with a show custom dialog (or merge variables on your layout) to check the values the next time that your script fails.
I have the field set up as a button with the action being "insert file" so that the users don't have the option of using insert picture. Then a script trigger runs the other script "on modify".
The area for inserting the files is set up in a portal with just the container field in it so that as the user populates it becomes a column of containers.
Another "viewing" layout shows the same column and the users can click on the files and they will open up.
Then phase two is to check the values of all the variables and fields involved in specifying file names and file paths the next time this fails.
You might also double check how each computer maps/mounts the shared folder into which these files exported. If one of the workstations no longer maps/mounts correctly, that would explain the error message that FileMaker can't export the file.
I'd also check the file names of the inserted files to make sure that they aren't missing extensions. Also check to be sure that this isn't a case of the file extension being correctly specified for the file, but OS settings selected that hide the extension when you check the file names.
Now that you mention it, I have had issues before where I used that "create folder" script. If the user wasn't connected to the server it created a folder on their own drive in the hidden /Volumes on the Macs. I have my Mac (and those in my department) open a folder on the server on log in, so that doesn't happen much to me. Will have to check on the others computers. Once that is created, the actual server shows up in /Volumes as Mini-Mac-1 and the script will keep going to the local folder rather than the server until you find and delete the local one.
The create folder script is an applescript I found on here a while back. I think there was one that made sure the server was mounted as well. Will have to hunt it down.
And such an AppleScript will not create a folder when the file is open on a Windows Computer. You'll need a different system script to create that folder when this is open on a windows machine.
We only have 2 windows users, I have an "If" platform step in the script that takes care of them.
I have advanced and tried running debugger and Data viewer on the script - the variables look right but the file gets exported into the Customer-part Spec folder not the customers subfolder and the filename is the customer's name, not the value of $newname
We only have 2 windows users,
Yes but that If step does not create any new folders.
the variables look right but the file gets exported into the Customer-part Spec folder not the customers subfolder and the filename is the customer's name, not the value of $newname
Then it doesn't sound like the variables are getting the correct values in every case.
You might want to set up this watch expression in the data viewer:
GetAsText ( incoming::Incoming )
To double check the exact text being used to compute a value for your File Name.
I have special folder for them that gets manually sorted out for now.
I set up a custom dialog step with the GetAsText (incoming::incoming) as the message. It gives the expected value- the actual file name with extension.
The export step still saves the file as the wrong file name/ wrong place. Then the insert file step inserts that back.
I really don't see how you can have the correct file name and path in the variables and yet have a file created and saved with a different name.
I just don't see how that could be possible. I have to wonder if the file you see with the wrong file name is actually a file that was created by the script at the time you watched the script execute in the Debugger instead of being a file created earlier under circumstances that produced a different file name.
I don't either. So as an experiment I went back through some "open" quotes ( someone started and never finished) and tried adding the file. It worked perfectly. The only difference was the customer name. I was going to copy and paste each of them here and noticed that the one that did not work had a CR at the end of the name. That must be what is messing up the $filepath since I don't think any OSs like CRs in the file path.
The customer name is passed to Quotes from the contacts DB. Someone must have entered a CR or copy/pasted them in when adding some of the contacts. Will have to go through and clean up all the contacts.
Replace field contents with calculated value:
Substitute (self, "¶", "") should work, wouldn't it?
That should strip out the return. but date extracted using GetValue should not include a return character. But then you may be referring to the folder name rather than the file name.
I will also note that no part of your script directly specifies the file name. It extracts it from incoming::incoming. Likewise, the folder name comes from a field.
So in both cases, we may be looking at data that is incorrectly entered into fields. GIGO
Looking back at it, it is a little confusing. In my mind when I built it, it made sense to have a field called foldername so I could see it easily. That field is a calculation field that is "constant part of the file path" & "/"& company name. Company name comes from the contacts DB. I could probably clean that up a bit now that I'm more familiar with the setVar and calculations.
The replace contents using the substitute did work for stripping out the return characters. I also ran a Trim on the field to remove any trailing spaces. I then went into the field definition for the contacts::company name field and made it auto entered calculation that removed any returns and trailing spaces. So now if anyone tries to enter a contact and use a return character in the company name or adds trailing spaces, the field automatically strips them out.
The file name could be an issue if someone ever tried to insert a file with a nasty character in the file name, but I don't think that has happened yet. I'm not sure what character you could use in a file name that would mess things up.
Yet all of these factors would explain getting an error message instead of a properly exported file, but it does not explain getting a file saved to the wrong name in the wrong folder.
The wrong name/wrong folder issue was caused by the ¶ in contacts::company name.
So that /Mini-Mac/Misc Work/$filepath/$newname"
Would be /Mini-Mac/Misc Work/Specifications/Honey Well¶ / 1234-datasheet.pdf
Which when the script tries to save, results in a file named "Honey Well" getting saved into the Specifications folder because everything after the ¶ is ignored.
By eliminating the ¶, I get a file named 1234-datasheet.pdf saved into the Honey Well folder within the Specifications folder as desired/expected. Which is in turn then reinserted, as reference, to that server version of the file.