I checked the container object and there is no a script trigger.
I moved the Set Error Capture [ON] before the export step, but nothing happen, the error dialog still displayed.
Ramón Álvarez Baeza:
Thank you for your post.
Our Development and Testing departments are aware of this issue. Currently, this error is not suppressible because in the general case, this error cannot be recovered from. Set Error Capture does not suppress the return of the error code; it just suppresses some of the alerts that are generated when turned on. That is, once you get the alert, you can still evaluate for error 800 in the next script step.
I have attached your post to the original report. When more information becomes available, I will post again.
This error is usually caused as a result of an error in the file path. There could be an illegal character in the path for example.
Hi! Rick Whitelaw I know that one of the paths is bad because it does not exist on the disk and the other one no, but, It's for this reason that I what to get this error, because i want to know what is the correct path.
Even if you could capture this error it wouldn't get you any closer to getting a correct file path. It would be trial and error. As stated previously, the error cannot be trapped because there is no recovery from the error. If I remember correctly I used to get this error because of unescaped back slashes (\) and slashes (/).
I'm not sure that I follow the "not recoverable" explanation here. "Not recoverable" from what?
The multiple inconsistent ways that FileMaker scripts respond to errors is one of the major head aches we have to handle and I'd love to be able to replace FileMaker's error dialog with one of my own that is less confusing and reflects the user context in which it occurred.
My sense is that TSGal meant that this error announces a "dead end" and that branching as a result of trapping this error would be of no use. I don't agree with this as something as simple as showing a custom dialog would be useful for example . . . Edit: I trap for illegal characters in file paths to preempt this error.
My apologies. I saw Ramón's last post and didn't see your post. If it weren't for "Rick Whitelaw" post, I would have never answered.
Rick Whitelaw's post is correct (Thank you!). I apologize for the wording of my post.
The information from Development suggests this probably will not change, so I recommend entering this as a suggestion into the Feature Requests web form at:
Entries into this web form populate a database file that is managed by Product Management and Development. All entries are discussed and considered for future releases. Although I could copy all of your posts and paste them into the web form, there are a couple of contact questions on the web form that only you individually can answer.
When posting the suggestion, please don't say "Add this feature". Make a case why you believe this issue is important to you and your clients.
I will point out that I made such a Feature request in the context of a larger issue--inconsistent and inefficient error handling in FileMaker Scripts. For my take on this, see: http://forums.filemaker.com/posts/56b3613440
To me this reads like: "We haven't set up a way for Filemaker to gracefully handle the error result from a "write failure" and don't plan to change this. That's very unfortunate as this particular generic error message is the source of much confusion amongst both users and developers new to FileMaker.
And there are cases where such an error might not need any user action at all nor would they need to be notified of the error if the script can successfully handle the error condition once it is detected.