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

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 ???

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, 200817 yr by Guest

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?

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

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, 200817 yr by Guest
Added PS

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.

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

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.

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, 200817 yr by Guest
Added update

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?

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:

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, 200817 yr by Guest

FileMaker knows the error condition at any given moment

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

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, 200817 yr by Guest

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

Nope, it's all invoiced and taxed properly.

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.

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, 200817 yr by Guest
Added update

"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, 200817 yr by Guest

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, 200817 yr by Guest

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

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

Byzantine Generals' Problem

Edited July 30, 200817 yr by Guest

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.

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?

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

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?

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

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

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.

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, 200817 yr by Guest

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

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?

Ahm... I said a local file.

Indeed you did. :blush2:

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.

So what *work* would I perform to solve this issue: import bot runs at night. If , email Admin and halt sub-script.

Aren't these questions that can be queried from the operating system? Would it be possible to run a bash script to check for the presence of your network connection and then proceed accordingly?

Vaughan, you aren't talking to the newbie you helped when I first discovered FileMaker. Yes, I had the script wrong because I was quite tired and I typed it from memory. But if you will have seen, I had it right all through this thread and obviously know scripting enough to know how it should be. It might help if you knew that I have used FileMaker easily 14 hours a day since I discovered it 4 1/2 years ago. I am no longer a newbie and would appreciate it if you didn't treat me as such. The reason for the break is NOT because of the way I typed the script. Have you tested it yourself?

We are talking about a forced disconnection and not business as usual. Of course the error capture normally works but it DOES NOT WORK when connection is lost. Repeat: FileMaker does NOT throw the errors it should. So here are the tests and I ask that you replicate them. File called Interfaces with external data source to file called Data which is served and on another box. Relationship between them; doesn't matter what. Fields from Data placed on Interfaces (at least a few fields). Serve the Data file and open Interfaces. Create two scripts and yes they are typed from memory:

Script 1 ( test Open File ):

Set Error Capture [ on ]

Open File [ "Data" ]

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

Show Dialog [ OK ; $$error ]

Script 2 ( test Set Field ):

Set Error Capture [ on ]

Set Field [ Data::anyField ; "test" ]

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

Show Dialog [ OK ; $$error ]

Run Script 1. It will correctly display 0 (no errors) as it should. Same with script 2 (or, depending upon how you related it, it might produce 510 but regardless, it responds properly). If you wish, create another script to test Open Record Request but it doesn't matter ... because I am on Interfaces and to use Open Record Request, I must go to the Data file. Once there, I cannot run my Set Field script steps because the POV (point of view) is incorrect for creating the Data records. Test everything while the Data file is being served properly.

Now close the served files or shut off power; trash it out. How you disconnect makes no difference; I've tried it both ways. On Interfaces file, you will receive dialog that FileMaker was forcefully disconnected (if you closed the Data file) and dialog that 'Connection was lost' if you cut the power on the server. Say OK to the dialog. Your Data fields will appear normal for a few seconds but will shortly change to . After a few more minutes they will instead change to . It is this state that I am attempting to capture because it is at this state that my bot scripts will run unprotected and unattended. If you run script 1 now, what do you get? Unless there are OS differences, it will STILL produce 0 errors. Same with Script 2. See now where I am going here? BTW, after a period of time if you bop around in that Interfaces file, FileMaker seems to eventually get the hint that something is broken. At that point, your scripts will change to but it doesn't happen at first. And it should.

In truth, I'm getting burned out on trying to explain the issues here. I know how to test but I feel like you are passing off my comments as childish panderings. I have more servers available than I know what to do with. I am getting paid to test and understand these issues. I am responsible for moving data representing several billion dollars in commitments. I do not take this lightly so please do not brush me off like a ding-dong. I do NOT make it up; I am NOT on drugs (sometimes wish I was) and I am NOT a newbie.

So, Vaughan, now what do YOUR tests show?

ps - I'm still waiting for the list of which error codes can be thrown via script. :wink2:

Matthew, maybe that is true. But 5003 may be fine if pinged; the server box may be fine; packets may pass properly; even FMS Admin may be fine. Maybe one file only trashed out - but it might be the one I need! I am not asking for miracles here - just simply to understand the rules of WHAT enigma codes, errr, error codes are thrown WHEN ... and to point out that it breaks if connection is lost. I will keep your suggestion in mind; thank you for offering it.

I have to say that FileMaker is absolutely silly when they expect us to create a global or a variable simply to hold the Get ( Last Error ). Why in heavens name can't this work:

Set Error Capture [ On ]

... do something

Show Custom Dialog [ OK ; Get ( LastError ) ]

... oh no, that would be too easy for us. Instead we have to move the puppy to something else and then grab it from there. Get real, FileMaker!! It reminds me of the issue of having to make a Value List simply to grab an index. If I didn't make my living using FileMaker, I'd laugh but because I do, I feel like crying about how stupid it is. It causes so much extra work for me (and all other developers).

"Vaughan, you aren't talking to the newbie you helped when I first discovered FileMaker. Yes, I had the script wrong because I was quite tired and I typed it from memory. But if you will have seen, I had it right all through this thread and obviously know scripting enough to know how it should be. It might help if you knew that I have used FileMaker easily 14 hours a day since I discovered it 4 1/2 years ago. I am no longer a newbie and would appreciate it if you didn't treat me as such. The reason for the break is NOT because of the way I typed the script. Have you tested it yourself?"

Umm, I was trying to be helpful. Looking for things that may have been overlooked. Let me know which part of my comment "In this code, the Set Error Capture step is being error checked, not the Open File step." is offensive and treats you as a newbie, and I'll remove it.

"File called Interfaces with external data source to file called Data which is served and on another box. "

Rather than checking for an error, would a check for IsEmpty( Data::PrimaryKey ) provide a useful indicator that the table is unavailable?

Granted that the error checking isn't working, we need to look for work-arounds.

Rather than checking for an error, would a check for IsEmpty( Data::PrimaryKey ) provide a useful indicator that the table is unavailable?

I mentioned this several times as a duct-tape workaround. I will report to FileMaker that error trapping breaks if connection is lost. This is why I suggested a new function - Get ( CurrentError ), an unstored calculation showing the current error state instead of expecting us to create a situation to trap for it (creating a variable or global to grab it and requiring we fire a script step just to generate it) and then depend upon an enigma code which may or may not even apply. And since nobody has a list of which error codes are truly thrown in any given situation, I suggested it be a design function so the one we THINK will be thrown will probably be in the multiline.

I really don't understand your suggestion. Design functions are about database structure. I don't see how Get (CurrentError) - or anything 'current' - would fit in there. We already have a Get (CurrentError) function - that's exactly what Get (LastError) does. The only "problem" is that the register is wiped clean before each new script step. But without this, there would be no way to tell which step generated which error.

nobody has a list of which error codes are truly thrown in any given situation

I'm not sure even FMI programmers could tell you with certainty which errors a script step MIGHT generate. If they had such foresight, there wouldn't be any bugs. Besides, ... let me put it this way:

There *IS* a solution to the Two Generals Problem. Not in theory, but in practice. Each general has an army at his disposal, and if they both throw the full resources of their armies at their communication problem, they'll have an overwhelming chance to succeed. They won't have enough resources left for the actual fight, though.

I will back off for now simply because I'm too tired to do otherwise. But it will remain on MY plate of things I plan to fix or more thoroughly understand and control.

I really loved the links provided. Michael? Vaughan? Matthew? Thank you all for hanging in there with me and taking the time to respond. I've decided not to post this for Steven because I don't think it will do any good. On this issue at least (and for now at least), I'm feeling temporarily resigned.

But it won't last long! :jester:

Oh, I can't help it ...

I don't see how Get (CurrentError) - or anything 'current' - would fit in there. We already have a Get (CurrentError) function - that's exactly what Get (LastError) does. The only "problem" is that the register is wiped clean before each new script step. But without this, there would be no way to tell which step generated which error.

There is BIG DIFFERENCE. Get ( LastError ) requires a script step. A new function such as Get ( CurrentError ) would not require a script step. If you look at FMS logs, you will see it logs all errors. FM KNOWS all errors that are happening; it must. All I am asking for is to know the error (or all errors in multiline) which are happening now.

If FM knows to display then it has identified an error without a script step. As you have said as well, calculations can throw errors. ALL errors are important to view - not just only when one script step has been performed because this is so limiting! It is always backwards - this function says "Do something and then see if it is wrong." Great.

It works sometimes but even on such things as import, it would be nice if it could be slid in BEFORE the actual action; kinda like a test, ie, "if I import, will it work?" Okay, okay, I realize that one is getting out there a ways. But the CURRENT STATE of a record or table and particularly a data source *is* known beforehand; that's what unstored calculations are for - to recalculate when viewed. But calculations are based upon fields within tables and THAT'S why I mention design functions because they look at least at an entire FILE.

Okay, now I'll stop. :tongue2:

I think this is an interesting discussion, I don't know why you sigh (if that's what you do). But I am still trying to understand what you're asking for. I assume you're not asking for a crystal ball - but that's what it would take to tell you the error of a future action.

It sounds like you want some kind of a diagnostic check of the entire system - but I don't see how that could be achieved without the system going out and actually trying every conceivable action. I am not a programmer, but it doesn't seem like something that could be brought to a reasonable performance by applying reasonable effort.

I agree about the log thing - it would be nice to have access to it (and not just on server), and also to have some more control over it (why does it always create a file when importing?).

I haven't forgotten about this thread. I am running tests as I have time. No, I didn't sigh, Michael, I find it quite interesting as well and that's why I posted back on here. But until I can pin down some oddities that I've found and can substantiate some findings, I'm holding off in my response at the moment.

In meantime, I am still attempting to protect from the unexpected disconnects...

Aren't these questions that can be queried from the operating system? Would it be possible to run a bash script to check for the presence of your network connection and then proceed accordingly?

Well, I'm trying to add this protection into my process but I could use some assistance. Ping alone just tells me if the box is up and it cannot (or *I* cannot get it to) ping the port itself to see if FMS Admin Console is frozen.

So I run telnet 10.xxx.xxx.xxx 5003

It doesn't return anything even when FMS Admin Console is running. If I can get a response then I am hoping I can redirect the output to a file just like I can with ping, ie, ping 10.xxx.xxx.xxx > ping.txt. Once a file, I can import it into FM and read the results via script and proceed accordingly. Matthew? Do you or anyone have ideas on how to capture the output or have ideas on how else I can test port 5003?

LaRetta

Okay I got telnet to work; seems that, if it is working, it produces nothing. So I closed the databases and tried again and it tells me that it could not connect! YAY! But when I redirect it to a file, it creates a blank file. I don't think telnet likes the old DOS redirect command. It certainly isn't listed in telnet's options but telnet doesn't have anything similar which might capture the output as a file.

Since telnet open an active session, you cant really pipe out it results out to a file.

If you use:

ping YourServer 5003 it will return blank if the por is working properly. It will return a connection can not open to that port.

One might think that ping YourServer 5003 > Results.txt would work but it doesnt since it was an active session.

You can use the following tools to help you check if a port is actively listening.

1. PortQry (Windows)

2. Netcat (UNIX, Windows (Atstake taken over by Symantec so harder to find windows version)

3. VBScript with an additional free downloadable DLL called W3Sockets.

(I talked to Wim and he confirmed that it can not be done just with VBScript alone)

If your port on that server is actively listening, then the FM Server should be okay. If it has stopped communicating on that port then you got an issue. :(

Wow, John, you solved it for me! Thank you so VERY much!! I had spent several hours researching answers to the fact that Telnet won't redirect to a file!! Using PortQry, my scheduler script first checks that port 5003 on the server box is listening. If not, it closes itself and never fires my other file's processing script. Pseudo code I came up with is:

Send Event [ "aevt" ; "odoc" (send the open document/application) ; Text: drive:portqry -n xx.xxx.xxx.xxx -e 5003 -l myserverlog.txt -y -q ]

Import [ no dialog ; "Myserverlog.txt" ] ... see note below ...

If [ PatternCount ( field ; "Not listening" ) ]

Send Mail [ email address ; "process could not run. FMS down."]

Else

Perform Script [ "Fire Process" ; From File: Interfaces ]

End If

Delete All Records

Close File [ current file ]

And then you present me with an FM file which uses web viewer so I don't even have to import at all! What a great learning experience! It is like this:

1) Web viewer with: "file:///x:full pathfolder/myserverlog.txt" (nothing checked below in web viewer). Attach object name 'TextViewer' to the field (in Object Info).

2) Calculation called cContentShow (result is text) = GetLayoutObjectAttribute ( "TextViewer"; "content" ) unstored.

3) Calculation called cFlag (result is number) = PatternCount ( GetLayoutObjectAttribute ( "TextViewer"; "content" ); "NOT LISTENING" )

Of course I shouldn't need #3 because I will test for that in the script. But what a sweet way of eliminting imports - just check the file where it sits instead. It works wonderfully in this instance and I've had a wonderful day playing with (and learning) new things. And now my process won't hang at script start and won't even require a User halt. I love this business!!

*Note: I originally used a global text field and planned to import the entire text into it. But the log file generated did not cooperate - it kept making several records out of it no matter what I did. But I realized that record 22 always contained the phrase "not listening" so I included Go To Record/Request/Page [ by calculation: 22 ] before I checked for the pattern. It bothered me (and still does) that I could not pull the file into one single global field.

Edited August 15, 200817 yr by Guest
Added note about import