SIMPLIFY..., yes, scripts can be safely run

[Keith M. Davie]

Last week I posted about the demonstration which I have developed.

On April 7, Anatoli posted, "On the other hand I will gladly admit when I am wrong. And if you found the way which I can test and confirm your outcome, then I will pay you the money and endorse your solution with my authority whatever level I achieve.

I sent Anatoli my demonstration on April 7, to review and test. I thought this would be good since Anatoli has claimed to be a hacker, and I figured that if anyone could make the workaround not work it would be a hacker.

On April 8, Anatoli posted: "The "workaround" relies on SCRIPT (!) to check if somebody is running Script. In another words, the problem with single threaded FM is just elevated up to another level. FileMaker will still crash or stall if 2 people will try to run scripts."

Anatoli stated an opinion. He did not state that he had tested the workaround, even though he had the workaround and could have tested it.

On April 9, Anatoli posted: "2 users cannot run in the same moment script, scripts in the same file or in different files! PERIOD! Start script in one database in loop. Then start another script e.g. your "workaround". What happened?"

Well I happened to have a database file loop.fp5 which is simple in structure. It runs a scripted loop which increments a field by 1. I altered the script to include the steps necessary to run with my workaround. I set the script to start at 1 and increment to 5000. This takes the script about 4 seconds to complete. I set Web Security.fp5 for the file loop.fp5. I wrote a link into my demonstration. I wrote a format file to run the loop in my demonstration. I then performed the test which Anatoli requested, starting the loop script and then calling another script while the loop script was running. Satisfied with those results, I later changed the loop to increment to 10,000 (about an 8 second run) just to see if the results would be the same for a longer running script. I ran several different tests in relation to the loop both at the 5000 and 10000 increments.

Anatoli had asked "What happened?"

As I told Anatoli in an email, "What happened was (1) my workaround worked, the db files did not crash and (2) I realized what a poor web design it is to run a loop or any script which takes more than two seconds to complete."

In that email of Monday I offered to send Anatoli a copy of the demonstration with the link to run the loop and the instructions of what I did to perform HIS VALID TEST. Anatoli has apparently declined my offer. Here it is Wednesday and he has not shown the courtesy to respond to me.

Anatoli, you will recall, wrote, "On the other hand I will gladly admit when I am wrong."

Well Anatoli has had the opportunity to test my workaround. He never claimed that he crashed the workaround. Heck, he never claimed that he so much as tested the workaround. All he did was originally claim that, "IMHO - It cannot be done. How you can convince me?"

There is no way I can convince Anatoli if he will not test the workaround. And it appears that he has not tested it. Not even once. And it appears he does not want to test the loop which he said is a Valid Test and which I offered to him after creating a special edition of the demonstration just for his Valid Test.

Every test run so far has shown the workaround to be successful - including Anatoli's "Valid Test" of the loop. Anatoli appears to not want to run this test. Anatoli does not want to admit when he is wrong; certainly not gladly as he claimed.

When Anatoli posted, "FileMaker will still crash or stall if 2 people will try to run scripts." Anatoli disparaged my work without basis. For he had not once tried to test the workaround. Using the Valid Test which he structured but has refused to test for himself, the workaround kept FileMaker from crashing or stalling when the first script (loop) was running and the second script was called.

The workaround which I have developed will allow ScriptMaker

[Keith M. Davie]

Anatoli, you say you ran my script and it did not work. Which script or scripts did you call simultaneously? From which format file(s) did you run the script(s). What browser or browsers did you use?

In order to see what problems you had, it would be fair of you to inform me. You have never informed me of what you did, either by email or on these forums.

If you ran your loop script, how did you incorporate it into the solution. What code did you write into your loop script to make it work with the workaround?

Surely the fair thing to do would be to inform me of what you have done. You have never given me any hint that you did anything more than surmise that it would not run.

You may refer to what I am saying as bull...., but you have provided me with nothing other than an unsupported opinion.

SIMPLIFY...

Keith

[Keith M. Davie]

Anatoli, above you made the statement, "I've run your solution and it DID NOT WORKED. Period. I've written that to you."

I have reviewed all the emails from you.

By email on Sunday I wrote to you "You did not crash it."

Your response (Date: Sun, 8 Apr 2001 18:12:59 +0200): "I did not tried. I can crash it in 2 minutes. As soon, as I will call from web 1 routine in scripts running 20 minutes (translating CE coding to FileMaker or vice versa) and try simultaneously your "workaround" script, or ANY other script the system will halt or crash.

"The outcome will be frozen FM or frozen Machine."

Needless to say, you have drawn your conclusion before you have even tested the workaround. You told me so in those sentences.

Aside from a script which takes 20 minutes to run being a bad web design/application, you did not try. That you did not try is what you said to me in that quote.

If you did try to run your 20 minute script and test my workaround against it, you would have had to make changes to your database file containing that script. If it involves another db file of yours, you would have had to include that file in the workaround as well. If you are going to claim that you actually ran this 20 minute loop script, then you need to advise me of how you set that database to run in conjunction with my workaround. If you did nothing to your database file, then the workaround CAN NOT WORK. If you did not set things up properly to test this loop against the workaround, don't blame the workaround. So far, all you've done is blame the workaround and claim, "I did not tried."

SIMPLIFY...

Keith

[Anatoli]

I've run your solution and it DID NOT WORKED. Period. I've written that to you.

If people want to pay you for that, that is fine with me. Be rich.

To execute 2 scripts in 1 copy of FM in the same time, well you discover Perpetum Mobile.

I am nominating you for Nobel Price.

Anatoli Kohout

FileMaker Tech. Support

East Europe.

[Anatoli]

Couldn't we start with test if FM can in the same moment execute 2 scripts in parallel?

[Keith M. Davie]

Since this is a browser solution, the tests must be performed from the browsers. While in development it is possible to perform certain preliminary tests in the db files, it is still necessary to run everything through the browsers. The workaround is a browser solution for the problem. I understand that a FileMaker soultion which is shared directly over a LAN can encounter similar jamming problems and that a different solution is required to solve that problem. My workaround is for browser publishing.

When I first learned of the problem of the single-thread, I had my demonstration running scripts without any workaround. In order to see the problem of near-simultaneous calls, I ran the demonstration and opened Internet Explorer (IE) and Netscape (NN) such that NN was the top half of my video screen and IE the bottom half. While this is an inconvenient arrangement, the inconvenience is temporary. There were times a more inconvenient arrangement was made such that each bowser took up one-quarter of the screen, and the db files took up the other half of the screen. But inconvenience is a way of life for the developer.

At that time I was running the script 'check' from the page register.htm. I found that if I entered data in all the fields of both browsers and then clicked first on IE, a message would appear saying that I was submitting an insecure document. I could then hit my Return (Enter) key and, with my pointer positioned above the NN window, if I double clicked quickly I would first click to activate the NN window and 2nd click to activate the button. Done quickly enough this allowed the near-simultaneous call to proceed and the result was the jammed db files and the incorrect message going to the client whose script did not run.

I sent the demonstration as it was at that time to FileMaker (case #2235305) and gave them the above instructions. They reported to me that they were able to see the problem as I had presented it and the problem had been given to their "Development Department". As I still have not heard back from them (it is now approaching three months), I can only imagine what this problem is "developing" at FileMaker.

With the re-written demonstration I have broken that script out from register.htm. Now register.htm just creates a new record in register_.fp5 and takes the client to pword.htm. There the client is asked to register their favorite password, but it must be unique and if the password is already in use, they will be so advised and will be required to enter a different password. While this may not be great web design (web design is a matter for each developer to determine), this is more a demonstration of technique and the use of cdml tags. So now if you open both browsers with the demonstration running, you can register a different person in each browser. At that entry IE will give the notice of the insecure document.

The next step is on pword.htm where the script is now run. No notices are given by IE from here. The process is to enter a password into NN but do not click the button. Instead click into IE and then click back on NN. This is to make sure the button there is stationary. Sometimes on clicking back on NN the button will jump/move from where it was. It is important to get the button on NN in a stationary position. When that has been achieved, then go into IE and enter a password. Now position your pointer above the button in NN. If you will now hit your Return (Enter) key, the IE window will send the request. As soon as you have hit your Return (Enter) key, you must double-click so that click one activates the NN window and click two activates the NN button. Done quickly, this will cause a near-simultaneous call of two scripts (or in this case the simultaneous call of the same script, 'check', from two clients). Every time I have performed this test, the workaround has performed as it should.

Another test is similar. Here one client is registered and is at pword.htm. The other client, already fully registered, has used option 5 (home.htm) and is going to make entry to begin to make a new record in comment_.fp5 via confirm.htm. When the the username and password is entered on confirm.htm and that button is activated, a script, 'newrecord' is run. Thus one can, as an example, enter the username and password in NN at confirm.htm and make the button stationary, as above, and then enter a password in IE, position the pointer above NN's button, hit the Return key and double click on NN and its button. This now calls different scripts ('check' and 'newrecord') in a near simultaneous fashion. If done properly, the IE client should be advised that their password was entered (assuming it is unique, which at this point is easy enough to ensure since the demonstration comes will only 12 used passwords). And the client using NN should receive the oops.htm. If the script 'newrecord' had run, the client would be given newrec.htm.. (Again, this may not be the best choice stylistically, but this is a demonstration of cdml tags usage as well as a demonstration of the workaround. Style concerns are ultimately the responsibility of each developer and will depend on many factors.)

The point at this moment is to make near-simultaneous calls on scripts using cdml -script tags to see if the workaround actually works as I say it does; not to get distracted by style concerns.

Another similar test can be performed when a client has data entered in the textarea on lastchnc.htm and clicks that button (calls the script "destroy"). This too can be run against a near-simultaneous call of the script 'check' from pword.htm.

The reason for using IE for calling the script from pword.htm is that the IE button can be activated by the Return (Enter) key. If one tries to use the Return key when the cursor is in the textarea, it just causes a line return (break). And by using the Return key, the pointer can be positioned over the other button (NN) ready to make the near-simultaneous request. Otherwise you could not move the pointer fast enough to make the near-simultaneous call.

Please try these tests on the demonstration as it was sent to you. The workaround is set (coded) for the demonstration. See if what I am saying works for you. Please give this an honest test. If these tests satisfy you, we can then move on to a loop test.

SIMPLIFY...

Keith

[Anatoli]

quote:

---

Originally posted by Keith M. Davie:

Since this is a browser solution, the tests must be performed from the browsers.

Keith

---

Completely wrong assumption.

The engine is FileMaker. Browsers are not processing something; they are just the facades. Trigger. Display device.

If engine cannot process something...... so we cannot get result.

So my question is still the same -- we are running in circles -- cam FM execute 2 scripts in one moment?

[Keith M. Davie]

Anatoli, I do not understand what your question has to do with your calling two scripts near-simultaneously in the demonstration and seeing what the demonstration does in response to that near-simultaneous call. Please test the demonstration. After you see those results we can maybe discuss whatever it is your question is? The last that you told me was that you had not tried to test the demonstration. That was last Sunday. When are you going to try the near-simultaneous call test on the demonstration as the demonstration was presented? That was what you originally agreed to do. You wanted me to convince you. If you do not run the test on the demonstration as presented, there is no way to convince you. That is because you have not looked. All I ask is that you be fair and honest.

SIMPLIFY...

Keith

[Kurt Knippel]

::Puts administrator hat on::

Ok guys, lets make sure that we keep the gloves on and keeps things civilized. Keith has a solutions that he believes works in a given situation. Anatoli believes that it does not. I am not web/cdml literate enough to know.

Now regardless of whether Keith's specific solutions actually works or not, I think that he is on the right track. His implementation may not work in all (or most) situations, but it at least works in some situations and if people are willing to pay him for this and use his solution, then more power to him.

If someone has a better way to implement this, or want to point out flaws to Keith, then I am sure that he will listen to your criticism. However like all good criticism, lets keep it constructive.

Saying that it does not work is not good enough. Let's hear what you exact situation is, or what problems you encountered.

Anyway, that is my little input.

[Anatoli]

OK,

So my question is stil the same -- we are running in circles -- can FM execute 2 scripts in one moment?

The so-called workaround is testing via script if another script is running. Does somebody seriously think that can work?

[signal]

We are running multiple users who often call the same script. Because it relied on some importing, we had to wait and wrote a simple script that checked to see if that script was running. If it was, we displayed a message and retried in two seconds. Seemed to work fine.

On another note, I would suggest you two stop writing each other. Anger is a very unprofessional emotion. Both of you have been helpful in various posts to other users but seeing the tirade from you guys would prevent me from ever wanting to hire out some work from either of you. And I DO hire out work.

This is a forum for helping, not insulting. I am insulted that you would take this public. Post a verifiable test somewhere and I am sure several of us would be happy to report our findings. I'm not a programming guru nor a hardware guru, but I can't really think of any single processor engine that can process two things at exactly the same time. Let's solve it.

[ April 13, 2001: Message edited by: signal ]

[Keith M. Davie]

Thank you signal, I agree. You write a script to see if a script is running, cause that works. A single server engine can run only one at a time.

SIMPLIFY ...

Keith

[ April 13, 2001: Message edited by: Keith M. Davie ]

[Keith M. Davie]

signal, I would like to thank you once again. Last night, as I was falling asleep, your post triggered the thought to me that some sort of error or corruption could have occurred during compression, transmission or decompression which could affect the demonstration. So with that in mind, the first thing I have done this morning is I have sent a new copy to Anatoli, along with an apology for my lack of understanding and missed communication.

SIMPLIFY ...

Keith

[Anatoli]

signal: Anger is a very unprofessional emotion.

Anatoli: me angry? Not in million years, And In writing? Where you get that idea?

signal: would prevent me from ever wanting to hire out some work from either of you. And I DO hire out work.

Anatoli: not my loss anyway

signal: I'm not a programming guru nor a hardware guru, but I can't really think of any single processor engine that can process two things at exactly the same time. Let's solve it.

Anatoli: It depends on OS and application. My single processor (in this case Celeron) is just running 283 processes in this very moment. In case of FM Unlimited, the single script-processing engine cannot run 2 scripts in the same time. And because the Windows NT multithreaded OS allows FM to do more things in parallel, even when the thread with one script is running, FM can still do -Find or -New etc.