Error disadvantages

[LaRetta]

I find the error codes and particularly Get ( LastError ) quite frustrating. Why? Because Get ( LastError ) can only be used when a script runs. If a script action actually produces multiple errors, which one displays? Example ... you want to set a field by the value in a related table. It could produce error 10 (requested data is missing), 100 File is missing, 103 Relationship is missing, 106 table is missing and ... do you see where I am going here ... there can be multiple error codes for one script action. But Get (LastError) doesn't produce a multiline of error codes; many times it produces none! Oh, I know we can just look for errors > 0 or boolean true on any error but that doesn't allow proper funneling of actions depending upon the error thrown.

And how wonderful it would be to easily take advantage of error 19 (string contains characters other than A-Z, a-z, 0-9)!! But it does us no good even if we are setting a field because we can't make it throw that error. Or take this one ... 207 (User does not have sufficient privileges to change database schedma, or file is not modifiable). If they aren't allow to change the schema they wouldn't be allowed in Define Databases. Oh, I'm sorry but I have more questions about the error codes than there are errors. In fact, how many different errors have people ever seen? I've been using FileMaker heavily for 5 years now and I've only seen a dozen error messages.

What has set me off this time? I'm attempting to throw an error (or generate a script-step to throw an error) if a data source I need is not present (error 117). But scripts act on tables. Tables are in Files. Files are based upon data sources. If not that error code, which to use? File Missing? Table Missing? So how can I test in a script if a file (in my data source which exists on another server) is available or whether the connection has been lost?

I can't start script with:

If [ Get ( LastError ) = 117

Halt Script

End If

... because something has to happen first. But if I import from a data source which has crashed (connection lost) then I receive NO ERROR - big fat zero and my scripts continue setting non-existant data (connection lost) from one table or file to another (connection lost). I have fixed in meantime by specifying a particular table which 80% of time is accessed. But I don't want to know if a table is available (I can check for IsEmpty (primary key) ... but rather whether the file or data source is available. Is my frustration showing?

Errors would be so powerful if we could use them and not as an inconsistent, hit-or-miss behavior which appears after the fact. Am I the only one who finds them perplexing, close-to-worthless, and frustrating?

LaRetta

[Matthew F]

Yes, I have also been frustrated by my inability to make a script determine whether a network connection is present. I've even made stupid dialogue boxes pop up that warn the user with statement along the lines of... "please make sure you have a network connection or else this script will fail". If someone knows how to do it I'd like to know.

Although I'd have to say that I'd rather have spotty error detection over none at all ???

[LaRetta]

Thank you for responding, Matthew!

Although I'd have to say that I'd rather have spotty error detection over none at al

That is like a wife saying she doesn't mind being beaten only once a month instead of every day. Unacceptable.

When I have time, I am going to somehow work to understand every error listed and more ... I am going to figure out how to more fully take advantage of the errors listed and I will also write my own conversation tables. Somehow.

In meantime, I will put forth a feature request. But I'm unsure how to explain it. It isn't that FileMaker doesn't provide us with enough error codes; goodness no ... the problem is that we cannot use scriptmaker to throw many of the errors listed so Get ( LastError ) is very limited.

We need a design function which, when used in a calculation, shows the CURRENT ERROR; maybe Get ( CurrentError ), set to unstored of course.

Edited July 29, 2008 by Guest

[comment]

Just a few notes:

There is only one list of error codes, and it's being used by scripts, calculations and (so it seems) by other processes as well. Some of these could be even internal, so you would never see those codes.

I don't think it's realistic to expect Get (LastError) to return multiple error codes: I believe (hope!) that as soon as the first possible error is encountered, the process is stopped.

if I import from a data source which has crashed (connection lost) then I receive NO ERROR

That is weird. Is this Filemaker or ODBC? Do other actions, e.g. setting a variable to a value from the data source, generate an arror?

[LaRetta]

Hi Michael! Thank you for responding!

There is only one list of error codes, and it's being used by scripts, calculations and (so it seems) by other processes as well. Some of these could be even internal, so you would never see those codes.

It would be quite helpful if errors (which can be SCRIPT generated) were flagged just as web-compatible script-steps currently are. I would bet that the lack of understanding (of error codes) is why most people just test for <>0. Life isn't all or nothing; script tests shouldn't usually be either. If anyone has a list of script-possible codes, I’d love to receive it. Otherwise, I plan on testing and creating one. I am convinced I'm not alone in my wonderings here.

I believe (hope!) that as soon as the first possible error is encountered, the process is stopped.

With all due respect, I do not agree. Using FileMaker’s own example:

Set Error Capture [On]

Perform Find [Restore]

Set Field [Table1::gErrorCaptureField; Get (LastError)]

#The field Table1::gErrorCaptureField is a global text field

If[Table1::gErrorCaptureField <> 0]

Show Custom Dialog ["Couldn't find the record..."]

End If

Firstly, yes, I use variables now instead of globals but they work the same in their results.

So envision … A User runs this script, searching the Contact name field for a customer and it says the hunted Contact isn’t in system by producing the above dialog, “Couldn’t find the record.” S/he then adds the Contact. What if, in fact, there has been corruption and the field isn’t there at all or the Developer accidently deleted it? The Contact IS there. Do you know the error message we WOULD receive? You might expect 102 (field is missing) but no. The code thrown is 508 (Invalid value entered in Find Mode). No, the value wasn’t invalid at all. So the User creates a duplicate Contact and even worst still … nobody knows that there is a serious error.

The reverse is also quite feasible, as in my current example. I am working with many internal and external sources all related to one FM data router. Some of these sources may not be available at any given time (either the SQL view is being modified; the FMS host has lost power; or simply there are no records). I want to act differently depending upon the error: if connection is lost to the served FM data source then I would want to fire an email to Admin and halt script. I want to check for the DATA SOURCE and not a field value (primary key) in a single table! And if SQL data source is unavailable, I would want the sub-script to exit but the remaining scripts in the process to run. If no records are found, that is a different set of directions to follow. We, as developers, are quite capable of branching properly if we know the rules. We provide the dialog saying what the error means but we don’t really know! Heck, we can’t even show the user the true error message – FM doesn’t have that ability. So I create Error table (which I did in my last solution) and modify the result message if necessary.

I don't think it's realistic to expect Get (LastError) to return multiple error codes:

Neither do I but I suggested that Get ( CurrentError ) be a design function because it would be multiline just as TableNames, LayoutNames and so forth. It would produce more than one error if more than one error is fired in any given situation. Why multiline? In any given scripting situation, there may be several error codes which you think would be thrown but aren’t – only to have error codes thrown that you wouldn’t expect or NO error thrown at all. Then if we want to test for 508, we could find it – even if the multiline produced (in hierarchy order) 417, 522, 508. Then we can trap using PatternCount() . Or maybe FM can tell us the hierarchy of errors (if more than one can apply); either way – we need more information. Between knowing which are script-generated (just as web compatible script steps are indicated) and all errors possible (by script) then we would be empowered to actively (and intelligently) trap for errors.

I will be posting the example of connection breaks but I had to get my REASONS for this post clarified first. Also then my example of it breaking will be more clear, I think.

LaRetta

[LaRetta]

I receive NO error here; not File Missing; Field Missing; Table Missing; Data Source Missing and it goes on ...

Test setup:

FileMaker file (Interfaces) on a regular PC with external reference to two other FileMaker files (Inbox and Data) being hosted by FMS9.0v3 on another box. Layout based upon Interfaces with relationship to the other two (and fields from related placed on the Interfaces layout).

Process:

Interfaces left on at all times (it needs to be). Data and Inbox being served at all times. Connection is fine. If I close the served files (whether properly or improperly), FM produces a message (‘FM forcefully closed’ if properly close served files; ‘Connection lost’ if improperly closed. Either way Interfaces receives one of these two dialogs with only an OK button. Nothing happens in Interfaces until the OK is dismissed – at which time, the scripts which were scheduled to start running BEFORE connection was lost will take off full speed. I have Allow User Abort [ON] and we manually stop it. But damage has already been done.

For ODBC, there is Get ( LastODBCError ) but it fails in this same type of scenario when accessing SQL tables. This example is ALL FM files. So what happens when we dismiss the dialog? Inbox and Data show but only for a few minutes. It then changes to .

At this point, I begin my test (and I can produce screen shots which shows my fields are based upon the proper table occurrences etc.:

Set Field [ Data::textField ; Inbox::textField ]

Error code produced? 0

I don’t get Field Not Found, Table not Found, File Not Found, and a dozen other error possibilities I should get! So how can I test whether a data source has lost connection? BTW, this fails the same whether script step is Import or Export. I haven’t tested the other script steps (and that’s why I’d like a list of script steps which can throw errors and WHAT errors they might throw). I’ve spent hours working through these error codes and it shouldn’t be this difficult. If I at least understood more what I was looking at with the error codes, it would sure help.

This is not the end of it for me. When I have time, I plan on understanding this all thoroughly. In meantime, if others have gone through similar experience and can share any wisdom, I would appreciate it greatly. I love learning on my own but it takes time I just don't have right now.

Michael? If you have other tests which might help me understand this, I will try anything! Currently I test for IsEmpty(Data::CapReqID) which is cheating. I love cheating but only when it is also logical, clean and safe. This isn't.

PS - it is difficult to throw errors and test. Many must be networked; some are user-activated (record-lock) etc. But it is all so very important to understand. Add SQL to the mix and, well, I have a lot to learn.

LaRetta

Edited July 29, 2008 by Guest
Added PS

[comment]

It seems to me we are talking about two issues as one. There is only one error code reported for each script step. I believe it is the code of first error encountered. It may not be the most significant error code - it could be only a side-effect of larger error that we would have received had the execution of the current step continued. But I don't think it does continue, so it doesn't get to the information you want.

Then there is another question of what happens next, as the script moves on to the following script step. The Get(LastError) is cleared, and the entire process begins from the top.

[comment]

I'm afraid I don't have a better suggestion - except to post this behavior in the server section, where Steven Blackwell reigns supreme.

[LaRetta]

Well. My test script only has:

Set Error Capture [ On ]

Set Field [ Data::text1; Inbox::text2 ]

Set Variable [ $$error; Get ( LastError ) ]

Show Custom Dialog [ Message: $$error; Buttons: “OK” ]

I guess I don't understand what you mean that it never gets to this. There is nothing in the script prior to what I am trapping; I set my test that way. So, because connection is lost, there is nothing I can possibly test?

Well now I feel the wind has been knocked out of me. Are you saying there is no way to even test Get ( LastError )? That we are at the mercy of an invisible mind which only thinks part of the time after the fact? So, not only can't I ever test for anything meaningful, I can't test the test. I'm quite discouraged here.

[LaRetta]

Well I don't see it as a server issue. It is an issue whenever any two systems share a file - the host can go down and error messages are worthless. I will not give up. This entire issue sucks. Error codes suck. But I will figure it out.

UPDATE: In fact, it isn't just when files are shared. The issues I've brought up are true even if only one system.

Edited July 29, 2008 by Guest
Added update

[comment]

I was referring to what you said earlier about getting the wrong error code (or rather not the code that best fits the real issue). I'm afraid I have no idea why you get NO error when trying to work with a source that went down.

The issues I've brought up are true even if only one system.

How can you get disconnected on a single system?

[LaRetta]

Not THOSE issues ... the frustration of not getting the error code you think you will. My fault, Michael - I mixed two issues. But they both revolved around error codes which I have renamed Enigma Codes. And I will own them before it's over. :smile2:

[LaRetta]

My point is this (and YES, sometimes points come after the discussion and sometimes points aren't even related to the discussion). ONE point is ... Get ( LastError ) is 'too little too late' and we should be able to know the current error condition at any moment because, you can bet your sweet cheeks that FileMaker knows the error condition at any given moment! And they are selfish not to share. Unstored design calculation (which applies to ALL files/tables etc) would fit the bill.

Edited July 30, 2008 by Guest

[comment]

FileMaker knows the error condition at any given moment

I wouldn't think so, but I am only speculating (and so are you : ).

[LaRetta]

To speculate a bit further ... FileMaker MUST know it because they know when to THROW it; whether calculation, script or whatever. An unstored calculation would be a simple display of what FileMaker would know at the moment they know it and at the same time they do the action they do in response to it; or don't do whatever they decide not to do to help us. They know; speculating of course. No?

Okay, okay ... I'll go in peace (for now). But again I disagree with you. What, are they sliding you money under the table again? Alpha 5 paid me last week. ROFLMFAO!!

Edited July 30, 2008 by Guest

[comment]

What, are they sliding you money under the table again?

Nope, it's all invoiced and taxed properly.

[Vaughan]

Hi LaRetta, I'm having difficulty understanding the problem. ;-(

FMP issues an error code after each script step is executed (except for comments). We're given access to the last code generated with the get( LastError ) function. We can choose where we trap for errors.

In general, files don't exist in a state of error. An error only occurs when the user tries to do something (like edit a record). The only exception would be the connection to a hosted file, but that's not really an error with the file (since it may work perfectly for other users).

Most of the time IMHO it's only necessary to know that an error has occurred, not exactly *what* the error error was. For this, Get( LastError ) <> 0 is sufficient.

Example: you need to drive to work but you car won't start. Knowing that the problem is a flat tire (101) or clogged fuel injectors (203) or lost car keys (1) or something else (-1) doesn't matter because from error <> 0 we can ascertain that we need to find other transport to get to work. (There are times when knowing the exact code is useful, but not for deciding whether to find different transport.)

I'm always careful about Set Error Capture status and only have it "on" when it's necessary, and "off" for all other times. So I'd use...

Set Error Capture [ on ]

Open Record

Set Variable [ $error ; Get( LastError ) ]

Set Error Capture [ off ]

If [ $error = 0 ]

# Record can be edited.

Else

#Error opening record.

End If

... that way I'm watching for errors I expect, but I'm letting FMP watch for the errors (and post alerts) for those I don't expect. In my experience it's the unexpected errors that cause problems.

[LaRetta]

In my experience it's the unexpected errors that cause problems.

I couldn't have said it better. But if a User isn't there, what would you suggest should happen if FM handles the error? That is not always possible and in our case it is impossible.

If my car won't run, I want to know as much information as to why as I can gather. If I don't have keys, I know to head back into the house. If it is out of gas, I know to call someone to bring a gallon of gas. And if the engine is blown, I know to get other transportation.

You make it sound like all or nothing; the very point about error codes I disagree with. Things are NOT all or nothing. We are smart enough to take additional action based upon specific codes (if we can) such as send email to Administration. to the main database which the entire scripting process writes to is important. It doesn't matter who could get to what ... it matters that there is an important script process which can't run until action is taken and, in our case, the action can NOT be handled by a person because nobody is there.

So I hear what you are saying but I do not think you provided an answer at all. You only reaffirmed the general head-trip of trap for anything or ignore everything. I believe that many intermediate steps can take place.

UPDATE: It's like using If() or Case(). I prefer Case() with more options. You'all seem to think in black and white If().

Edited July 30, 2008 by Guest
Added update

[Vaughan]

"But if a User isn't there, what would you suggest should happen if FM handles the error?"

Then you'll have to have a "plan B" for practically each and every script step... assume everything will break, and nothing can be taken for granted.

When a process requires editing a record, extra stuff might need to be added to trap for the record commit failing. The cause of the error might not be important, just the fact that the record cannot be committed might be enough to trigger some process to handle the problem.

This adds complexity enormously, but this is just the kind of coding that mission critical processes require, like for life support equipment and nuclear power plants. (Some OS software licenses specifically exclude their use for these purposes.) It takes orders of magnitude more time and effort to write and maintain. It's why the Space Shuttles still use 80286 processors.

For most of what I do (neither life support nor nuclear power plant) the trapping of most "unexpected" errors might just end with taking the user to a safe layout, issuing a custom dialog and halting the script. More critical stuff might require implementing roll-back processes and logging the errors. It depends.

But all of this is coding done by the developer. It's *work*. It cannot be solved by a new or improved function. We've got everything we need right now.

"If my car won't run, I want to know as much information as to why as I can gather."

For most processes I work with, errors should not occur since they should have been designed NOT to fail. (I'm thinking of things like checking for locked record in multi-user etc.) When a network drops out and a data source disappears, what use if knowing the error is "field missing" rather than "invalid relationship"? For that matter, what can the developer do?

The first time I did a First Aid course, we learned how to stop bleeding, do CPR, treat shock etc. I asked the trainer what would happen if a person had internal bleeding that I could not see; what could I do? Their answer was: First Aid cannot do anything for them; they might die; all I can do is get help.

I think error trapping with FMP is the same: there is only so much a developer can plan for and do: after that, it's fatal. Send a call for help and make the patient comfortable.

Edited July 30, 2008 by Guest

[LaRetta]

It's *work*. It cannot be solved by a new or improved function. We've got everything we need right now.

I am not afraid of work, sir. So what *work* would I perform to solve this issue: import bot runs at night. If , email Admin and halt sub-script. If SQL data source not found, exit sub-script. If records not found, create entry in Action Log and exit script. Otherwise process. What error code will show connection lost? I have a complex data-merge between many systems. Did you read my posts at all?

I am glad you think we've got everything we need right now. Oh sure, we do ... we have several hundred error codes that mean almost nothing. If someone wants to test for an error, they have to look at the error list and try to figure out (ON THEIR OWN) which error might be generated. And they will probably be wrong. We have everything we need but INFORMATION. But, since you know these error codes, you can provide me with a list of every error code which can be thrown by a script step, right? YAY! I don't want to trap for error codes which won't be thrown. Can we get to that point? :wink2:

Edited July 30, 2008 by Guest

[Vaughan]

Can you post some script code so I can know exactly what;s going on and what's breaking?

[Vaughan]

I just read this on Wikipaedia... it seems relevant to the discussion.

Byzantine Generals' Problem

Edited July 30, 2008 by Guest

[LaRetta]

Yes, Byzantine fault is exactly what I need to protect from. There is nothing wrong in the scripts and they have been running fine for 7 months. We have UPS as well on Interfaces box and our production server and both citrix servers are in building with backup power. But if our served files unexpectedly close then this Interfaces file changes to all the way through it. I use a Scheduler.fp7 which is fired from Windows Scheduler to run import/export/SQL scripts at night. Windows scheduler fires Scheduler which acts like an Opener - only job is to fire the Interfaces Action script then close itself. I can't have Interfaces be fired from Windows Scheduler directly because Admin does other work in Interfaces during the day.

So when it hangs on a 'Connect Lost' dialog with only an OK button, and someone hits OK, the Actions script takes off. I can hit Escape but it can go so fast that ...

OK. I give up for now. But this gives me an idea. I will have the Actions script pause for 30 seconds before it even begins. If there has been a problem, this will give a person time to Escape the script before it begins. My point, Vaughan, is that when connection is lost (see my one-line SetField[] test script above), I cannot test at the beginning of my Actions script whether the connection has been lost. If I import, that is AFTER THE FACT and that is too late and one of my beefs with Get (LastError ). And yes, a new function WOULD be helpful here. So to use Get ( LastError ), I have to do something first (perform a script step) to find out whether my data source exists. What can I do to test connection lost or if data source exists?

Some error codes need to be found out BEFORE hand. A 'data source' doesn't have a field so you can't test IsEmpty(primaryKey)!! Well now I've said it all twice using slightly different words. I have no idea what else to say. If you'all don't see the issue here then I must be in the wrong line of work.

[comment]

I see the issue, but I don't think you and I can solve it (at least not properly). So you need a workaround.

What actually happens when you import from a source that isn't there? I am still puzzled why you don't get an error, but even so - what is the practical result?

[LaRetta]

I'm sorry, Michael, I don't believe I'm being clear then. I can trap if an import fails because the file isn't available (it produces 100 when I trap the import step). When I say …

I cannot test at the beginning of my Actions script whether the connection has been lost. If I import, that is AFTER THE FACT and that is too late and one of my beefs with Get (LastError ).

... I mean that my script has already started, imports the primary keys into Interfaces and then begins writing to 8 different tables in the Data file.

I do not want to import into Interfaces if the data cannot be written on through; it is like picking up a heavy rock (to move it to another place) and having no place to set it back down. Immediately after import (when the rock is in my hands), I STILL can’t turn around to check whether there is a place available to set the rock down. If I could verify connection lost then I could delete the imported set and branch the logic on through depending upon the type of error.

What BREAKS is Set Field[] and error capturing after. It doesn’t tell me that the file, field, table, data source … nothing is available. No errors. It appears that it works when it does nothing. Worse still … there was one time the process ran all the way through after this type of disconnection. I am unsure whether the connection lost was on another file (other than Interfaces or Data) ie, we have a flat import from People Soft (can't use SQL here because it is dog slow). Connection was lost and then restored. But only some of my files/tables/SQL views etc, saw the reconnection; others didn’t refresh at same time and when the process ran through ... gulp ... it blanked out all of the information in the data file (for those records/fields being written to). I cannot replicate the exact same situation (and I hope I never have to again); I shudder thinking about it. And yes, I repaired the damage immediately and yes, I have protections built in that you wouldn’t believe but that's not the point at all. Some breaks may not be noticed until Users have modified the Data’s data and then going to a backup is problematic.

I've been playing with a few things (as workaround like you suggest) such as going to a table based upon the disconnected source (heretofore referred to as DS). Go To Layout[] doesn't generate error message. I need to include 'open record request' and then it tells me error 100. But I can find that out WITHOUT going to a data layout simply by checking for IsEmpty(CapReq::CapReqID). But again, this means zeroing in on fields and tables when I want a larger perspective (data source or files). Maybe I’ll start script with 1 minute pause to allow someone time to hit Escape before the process even begins.

Okay, I will try to quit *whining about something I can’t have, Michael, but I'd pay a fortune to be able to ask at the beginning of my script (when is displaying), "Is file missing? Is data source not present? Is connection lost?" I will probably add all three of these semi-fixes until/unless something solid comes along so any other ideas will be appreciated.

Oh, and Vaughan? I appreciate that link because I realize I admire Byzantine Commander and Lieutenant much more than their General and it helps me understand my oddities a bit more.

*I will not only whine - I will figure it out and I will give everyone a script-based error list AND a list of every script step and error codes which might be generated from it.

LaRetta

[comment]

I'm still not clear on one point: are you saying you are doing some other stuff before turning to import from the "disconnecting source"? If so, couldn't you make that import the first thing?

[LaRetta]

There is no import FROM a disconnected source. The imports are from SQL tables and other files to an intermediate file (Interfaces). Imports aren't my problem; they work and can be trapped. But Interfaces is an intermediate file which only imports the primary keys from many other data sources (mostly SQL but also FM files). Once only the keys are imported, the data itself (easily 150 fields of data) is written THROUGH the Interfaces router into many tables in the Data file (target) using Set Field[]. It is Set Field[] which will not throw an error if target is broken, doesn't exist or loses connection.

I would rather not import the keys if I know the connection is down to Data. But even if I import anyway, I STILL won't know whether connection to DATA is broken. So I must then find out somehow and this is my problem (how to find out). But I don't know if it is broken so it writes on to the Data file and it doesn't write because it is broken. Result? I have imported keys in Router with no related data in the Data file but batch in Router says 'no error; it ran fine'.

So basic process is:

1) Import from a data source only it's primary keys.

2) There is relationship from this data sources' primary key to Interfaces foreign key

2a)Interfaces ID is related on through to Data - in many different tables.

3) Write a lot of information through this relationship to the Data source file using Allow Creation.

4) This checks many other relationships, validates, converts and so forth.

5) I cannot import directly into Data; or rather, it is not the best choice.

6) The Set Fields[] do not throw an error and they should when the target is missing or has lost connection.

7) So new incoming data (and updates to information) won't end up in Data like it should.

This is simple step-through sequence. There is more to it and many more files, tables and views involved but that's the basics.

LaRetta

[comment]

OK, then how about Open File ["Data"]?

[LaRetta]

I was already home but I was so excited that I remoted in and tried it ...

Set Error Capture [ On ]

Set Variable [ $$error ; Get ( LastError ) ]

Open File [ "Data" ] ... selected from my list of external file sources

Show Custom Dialog [ OK ; $$error ]

results: 0

Dang. Thank you so much for trying.

[LaRetta]

Also strange is that scripts don't notice that the file is missing either, until I try to RUN a specific script. My other test script, which fixed itself when I re-served the Data file earlier, I expected now to show but it still doesn't. But after I fire it, it turns to where it sets the Data fields (but it STILL doesn't throw an error).

Edited July 30, 2008 by Guest

[comment]

It must be a server-related issue: I certainly get error 100 if I try to open a local file that isn't there.

[LaRetta]

Then I will take your earlier advice and post a simpler question (smile) over in Server section for Steven. I suppose it feels similar to tables lacking ability of seeing each other. But if a file shows , well, THAT'S what makes me think the current file should know!

BTW, are you opening a local file or are you selecting from a External Data source?

[comment]

Ahm... I said a local file.

[LaRetta]

Indeed you did. :blush2:

[Vaughan]

Sorry for the delatyed responses... dang those time zone!

I should have also posted the Two Generals Problem because it highlights the fact that there is NO solution to the problem of being certain that the message has gone through. Real life solutions do not attempt to eliminate the uncertainty, but mitigate it to an acceptable degree... I think this is applicable to our error checking problems.

What BREAKS is Set Field[] and error capturing after. It doesn’t tell me that the file, field, table, data source … nothing is available.

Use the Open Record script step, and trap for errors. Only lift the rock if the record can be opened. :

LaRetta then wrote:

Set Error Capture [ On ]

Set Variable [ $$error ; Get ( LastError ) ]

Open File [ "Data" ] ... selected from my list of external file sources

Show Custom Dialog [ OK ; $$error ]

In this code, the Set Error Capture step is being error checked, not the Open File step.