web "-script" solution

[Arin]

Correct me if I'm wrong, but I think I may have stumbled onto a solution for the -script problem with CDML.

I've got a machine running FMP 5 Server, then I've got 2 iMacs (1 OS 9.1-FMP5 Unlim & 1 OS X 10.0.4-FMP5.5 Demo) both accessing the same databases from that server, and then those 2 iMacs are sharing their databases with an OS X Server (v1.2) machine running Apache and FMP Unlimited WSC.

When a script is running (even one that hangs on a dialog box) the web request simply gets redirected to the other iMac. Depending on how many scripts you need to use, and how long they take you may need more machines (iMacs in this case) in between the two servers...

Let me know if anyone else is able to test this...

-Arin

[Anatoli]

I was the first person to warn people here about single threaded FM engine and my conclusions are that scripts and web is not happy marriage.

Just don’t use them.

[Arin]

My theory, and results from testing are that several "single threaded FM engines" hooked up together (running on the iMacs - 1 "engine" per mac) will function on the outside (to the web user) as a multi threaded machine.

I'm basing this on the fact that the actual script execution seems to take place on the iMac(s) rather than the FMP Server that is hosting the DB's. If this is not the case, then this may still be a viable solution once FMP Server 5.5 (Cocoa) comes out.

[Anatoli]

Scripts will be always only partially successful.

Example: to put current date in global field it will work all the time.

To find records by script and display them through HTML -- no way.

It may look it is working. But if first request (1) from user A will run the script, and another request from user B (2) will make different found set of records, then the machine will not display correct set of records to user A (3).

You cannot assume, that FM somehow will process the requests in 1-3-2 sequence.

[Arin]

I see your point Anatoli, searches in scripts would seem to always leave room for errors.

I'm running scripts that do things like check email (POP3it plug-in), or creat new records in a seperate unrelated DB with no direct web response (from the new DB), so I don't think that there is room for error, as there is no find, or sort commands that are going on in conjunction with the executing of the scripts.

The whole thing does make me wish FMP would either fix it in the next release, or remove support for the "-script" tag.

[Anatoli]

Yeah, you can use simple scripts running in split second without problem. Like Open and Close database remotely.

But I do recommend reworking your script for new record to Inline. I've build complete tracking system of visitors' movements in sophisticated portal with PR news in 10 minutes by Inline.

[erasmussen]

quote:

---

Originally posted by Anatoli:

Scripts will be always only partially successful.

Example: to put current date in global field it will work all the time.

To find records by script and display them through HTML -- no way.

It may look it is working. But if first request (1) from user A will run the script, and another request from user B (2) will make different found set of records, then the machine will not display correct set of records to user A (3).

You cannot assume, that FM somehow will process the requests in 1-3-2 sequence.

---

Are you saying that web companion will answer the request for B before FileMaker finishes running the script for A (i.e. scripts run without regard to synchronization with filemaker/web companion)? If so, what happens to the answer for A? Does web companion answer A before the script finishes, thus generating an incorrect response? Does web companion/filemaker actually process the requests in a non-FIFO (first-in, first-out) manner? In your example above, isn't 3 really part of 1, and 2 shouldn't be processed until the script completes? Does this also mean that a user at a regular filemaker client console could interfere with the proper operation of a script by using a keyboard/mouse to perform a command while the script was running in the background, or is this simply a problem with web companion?

-Eric

[Keith M. Davie]

"Does web companion answer A before the script finishes, thus generating an incorrect response?"

Yes. When two near-simultaneous requests are made on a script (or two different scripts) one client will be advised of a successful transaction, but the script will not have run because the single-threaded engine was busy processing the first request it received. FYI, Lasso must use the same single-thread engine.

There are several discussions on this problem. Review these forums. Some of us have claimed to have developed a workaround.

[Anatoli]

RE: Does this also mean that a user at a regular filemaker client console could interfere with the proper operation of a script by using a keyboard/mouse to perform a command while the script was running in the background...

If Unlimited is processing requests from Web, you will see all requests on the screen, like from invisible operator.

Now, if you want to work in the same moment with different requests what will happen?

Now, web will trigger script with response time of 30seconds. What you can do with another web request? Or console request?

Single thread is single thread. Queue of requests...

[Keith M. Davie]

"...web will trigger script with response time of 30seconds."

I would suggest that there are such a things as unintelligently written scripts. I would suggest that a script which runs for longer than one second in a web application is a very poor design. Poor design lacks thought.

If one wants to be really stupid, one can run a looping script which will take an hour to run. Not a good idea.

However, with an effective workaround, intelligently written, well designed scripts can be handled successfully in a multi-user environment.