Jump to content

Running Scripts online


This topic is 8464 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Yes, you need to use custom web publishing. Yes you use the cdml tag -script, among others.

Some people suggest you should avoid scripts. I suggest that you must be very careful in their structure and timing inregard to both database(s) and -format/-error results.

If you would like a practical demonstration including the successful use of scripts, see my posting under cdml from Jan 11 regarding a demonstration. It can help you get past the learning curve.

Peace

Keith M. Davie

Link to comment
Share on other sites

quote:

Originally posted by rooroo9:

I'm new to web publishing and have a databse with scripts in it. When i publish online the scripts don't run. Do i need to use CDML for this? If so is there any easy way to make scripts run? Thanks

Scripts are not for web.

Do everything in calculating fields.

If the script is running more than 0.5-1sec, and another visitor will ask for script you will experience big problems.

The WebCompanion is in fact single user as is its engine.

Link to comment
Share on other sites

Anatloi, Thank you for the heads up on the problem with multi-users and the -script tag. I am now very aware of the problem.

So is FileMaker. I have used my free Tech. question with them on this. The feeling I got was they were totally unaware of this problem. They are now fully aware of the problem. I sent them a format file/db solution with clear instructions on how to view the conflict (1) when the same script is accessed near simultaneously and (2) when two different scripts are accessed near simultaneously. I was advised that they followed my instructions and were able to view the problem.

Nowhere in their literature is there a caveat about the use of the cdml tag "-script". If they cannot provide a fix, I imagine we will need to see the demise of that tag as well as "-script.presort" and "-script.prefind".

Any site which currently is using -script in conjunction with ScriptMaker

Link to comment
Share on other sites

we use scripts semi-regularly (not massively). could you please expand on what type of problems are created? The problem i have is that the scripts do things that calc fields can't do. Accessing different databases, etc. Fortunately, the scripts are only running on our own internal systems so i won't make any clients mad. But stil would like to know.

jeremy

Link to comment
Share on other sites

Yes, simply put, if two near simultaneous requests are made via a browser on an action tag or action link which invokes a script in a database, whether it is the same script or different scripts, one script will run successfully, one script will not run, your database may well stop, waiting for someone to click the "continue" button in the status field (which they are unaware of because they don't see the db file), and both clients are given a successful results.htm page not an error page, so they believe that their action was successful. Only one of the two will be correct in their belief.

AT THIS TIME DO NOT USE THE CDML TAGS WHICH INVOKE -script, -script.prefind OR -script.presort. I HAVE A CASE WITH FILEMAKER ON THIS ISSUE AND AM AWAITING THEIR SOLUTION. THEY ARE NOW, AT LEAST, AWARE OF THIS VERY SERIOUS PROBLEM. They put no caveats in their literature on the use of the cdml -script tags of which I am aware. Welcome to the world of FrustrationMaker Pro.

Peace

Keith M. Davie

Link to comment
Share on other sites

I guess I am really good with FileMaker and Web. I've tested everything. The scripts are simply put not for web. As I wrote, WC IS SINGLEUSER. Maybe in 5 Machine RAIC scripts will be OK.

I was redesigning my entire web Solutions to have no scripts and it is not so hard. I have only 1 script on all web Solutions and I am basically lazy to get rid of it. It is just flagging one Today variable. It is running in fraction of second, so no big problems in the future.

Because of Power of calc fields and branching (If Else) in the calc fields and branching in HTML, I did not find major problems.

Of course, one must rethink the FileMaker programming. Do it the "other way".

Link to comment
Share on other sites

  • 2 weeks later...

Script In Use

There appears to be a work-around for near simultaneous activation of a script.

1. create a db file Script_In_Use.fp3 (or fp5 - this is good for FMPro 4 & 5) Also, you can use a shorter, more practical nomentclature. For browser solutions I recommend the eightdotthree protocol for naming. For this discussion I will call it inuse.fp3.

2. In that new db there are two fields, "constant" a calcultaion field value equal one, and "fill" a text field. One record is maintained in this db. ("constant' does not have to be displayed in your layout but "fill" does. "fill" is empty of data in this beginning mode.)

3. In your existing db(s) (we will select just one db file and call it script.fp3) which are running any script create a field "constant" a calculation field value equal to one (this does not need to be displayed in any layout)

4. create a relationship in your file script.fp3 with inuse.fp3 such that constant::constant and name it appropriately, lets use "check" for this discussion.

5. In your existing script (let me assume that your first line is Enter Browse Mode []), make your second and following lines read:

Allow User Abort [Off]

<!--this first line is necessary for a non-web solution, and can probably be left out, though its presence is no deterence to your purpose-->

If ["check::fill" , """]

Revert Record/Request [No dialog]

Halt Script

Else

Set Field ["check::fill" , "password"]

<!--In this instance "password" is the name of a field in your db script.fp3. A field with some unique data is probably best to use, though you may find other fields or a Status() option which meets your particular needs. The purpose is to cause the field "fill" in db inuse.fp3 to be filled with something, which keeps your other scripts, similarly constructed, from trying to run when a script is in use-->

<!--you now allow the rest of your script to run as you had it written-->

Set Field ["check::fill" , """"]

<!--your last line in the script or subscript, whichever is appropriate, should make certain that the field "fill" is left empty so that another script can access it and run-->

Realize that if a script is in use, the second script request will find that the relationship is not empty and will cause the Halt Script to occur, the effect of which is to cause the display of your error.htm format file. Thus you may want to construct that file with a refresh instruction such that it allows the currently running script to finish running before attempting (what amounts to) a re-submit of the data, and allowing again for an error.htm and a success.htm, while also informing the client that the "Request is being processed, please wait", or some such message.

While not necessarily elegant, it appears to be a useful work-around.

Peace

Keith M. Davie

[This message has been edited by Keith M. Davie (edited February 13, 2001).]

Link to comment
Share on other sites

Script In Use DOES NOT WORK AFTER ALL

Do not use the above solution. On closer examination it is not the workaround I initially thought it to be. While it solved part of the problem, that part was only minor. On further experimentation I discovered that the problem is deeper than the suggested work-around.

We are still at the condition of do not use the cdml tags, -script, -script.prefind and -script.presort in your browser solutions.

Enthusiasm once again kicked in the teeth by reality. Still searching ...

Peace

Keith M. Davie

Link to comment
Share on other sites

This topic is 8464 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.