Error I Can't Trap For When Exporting

[FritzMills]

In a hosted environment, I am building a scripted export that will export records to a tab delimited file in a directory that another (new custom) application will check every 5 minutes or so. If it finds a file, it will open it (exclusively) and import the data, and then it will delete the file. In order to avoid a situation where Person B exports a file that overwrites one Person A just exported (and before it was read by the new application), every export will contain all records previously exported that day. My thinking was that if the exported file was open and couldn't be overwritten (because the data was being read), I could trap for that error, wait a specified amount of time and try the export again. Although it will be a text file, I tested the concept by exporting a FM file, opening it, and then running the export script again. I get an error message that the script couldn't write the exported file to disk (and it gave me a variety of possible reasons why), but FM doesn't return an error code. I want to avoid using plugins for a variety of reasons. Does anyone have any suggestions?

[Vaughan]

Are you using the "Set Error capture [on]" script step?

[FritzMills]

Yes, I'm using "Set Error Capture (On)". I created a test calculation field to return the current error. When that kept coming up with a value of zero, I built a script that first Set Error Capture (On), and then had a bunch of If statements that tested for specific error codes that I thought this error condition might generate. It wrote its results to a global field. I tested for the following error codes, and the default value (if none of these error codes was returned by Status(CurrentErrorCode)) was 9999.

The error codes I tested for (in the order I tested) were:

300

800

809

801

810

951

974

-1

0

Else: 9999

In every case, "0" is written to the global field.

Conclusion: I don't think you can trap for this error. But I'm not very smart, and I think there's a good chance someone else has faced this problem and has figured out a clever way to get past it. Hopefully one of you can help me.

[BobWeaver]

Are you writing the error code to the global immediately after the export? Any intervening script steps (including comments) will reset the error code.

[djgogi]

Actually under OS X 10.2 no error at all will be generated, with or without set error capturing.

In fact when you export in already opened file, data are saved in temporary file:

Now if you close the text file without saving it and reopen it, the newly exported data will be shown.

Dj

[FritzMills]

In reply to BobWeaver, the only thing the database does is this one export. I built it solely to figure out which error code it would generate. So it exports and then immediately tests for the error code, and that's it. No comments, no nothing.

With respect to DJ's comments, it does generate an error in the sense that Filemaker puts up a dialog box that says it can't write the file and suggests a couple of possible reasons (file is write-protected, the disk is full, and one or two more). In any event, even if it did replace the contents when the file was closed, I don't know whether that would help, because the custom application is programmed to delete the file when it closes it.

It is true that I am doing this in OS X 10.2, but it will be deployed in a Windows environment (and Filemaker Server 5.0). Do you think it will behave differently under Windows?

Thanks. Fritz

[-Queue-]

The only time I've been able to get an export to return an error to FM in Windows is when the file is already open on the user's computer. If the directory doesn't exist or isn't accessible to the user, nothing happens. Windows might report an error, but FM doesn't, which is why I'd recommend using a batch file or a WinBatch file to trap any errors.

[FritzMills]

I _want_ to get an export to return an error to FM when the file is already open on the user's computer. Meaning, an error I can trap for with Status(CurrentError). I get an error, but only in the form of a dialog box. FM doesn't return an error code. What am I missing?

[djgogi]

OSX 10.2.6 and 10.2.8

FM Dev 6

No errors were generated when exporting in already opened file.

Dj

What I wanted to say is that thru "native" methods there is no simple (is there any?) way to solve this problem.

If it has to run on Windoz also than applescript is excluded too.

So try some plugin based solution, like TROI or NEWMILLENNIUM file plugs.