Error disadvantages

[Matthew F]

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?

[LaRetta]

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:

[LaRetta]

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]

"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.

[LaRetta]

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.

[comment]

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.

[LaRetta]

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:

[LaRetta]

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:

[comment]

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

[LaRetta]

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

[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.

[mr_vodka]

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. :(

[LaRetta]

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, 2008 by Guest
Added note about import