Server-side Schedules & Globals

[David Nelson]

1) Can a User activate a scheduled script? I read somewhere that Wim said we could use HTML but it was some twitter feed - there then gone and hours of research has not returned it to me. A link or example would be awesome if it's possible.

2) If scheduled script sets a global field (in a file it is serving) is that global value retained just as though it were manually set off line?

3) Are scheduled scripts always client? Do they always follow same rules as a User or are there exceptions where scheduled script would behave/evaluate differently (scripting, calculations, globals), possibly from different perspective?

4) If a scheduled script (as Client) has to retrieve values from the server, is it faster because the server is the same box? If so and if 1) is also possible, might it not be wise to fire all/most scripts as server-side or does the HTML portion slow it down to begin with which would outweigh the speed benefits on the other side? I guess this question is about 'perspective of evaluation' and 'local box vs. network.'?

I've researched quite a bit and I remain uncertain. I ask please here - of the top two people knowing server (Steven and Wim) and of course others who may know - for answers to these above four questions. And thank you for taking the time to read my request.

[Wim Decorte]

Hi David,

1) No, not a scheduled script. But triggering a script through an HTTP URL can be done. The difference is in what script steps are supported. Server schedules support different script steps than the web publishing engine does. Check out the difference before you go that route. For an example: check out the XSLT reference database that comes with Server, it shows how to construct the url that will run a script through the web publishing engine.

2) No. A global field will behave as a normal user's does.

3) Yes, same rules, no change in context

4) It's always faster, but I'm not sure I follow the mental link you make between server-side scheduled scripts and web-triggered scripts. Two very different beasts.

[David Nelson]

Hi Wim,

Thank you so much for answering. This helps me a lot. Then if 4 is true and I have a script which is very task intensive but it needs to be ran immediately and it needs to run fast, would it make sense to have the server as a client run it instead of a regular User, using web-triggered script?

[dansmith65]

would it make sense to have the server as a client run it instead of a regular User, using web-triggered script?

I think you are the only one that can decide if it's best for your database. It would probably only work for performing some sort of background task, since it will be run from a completely different context than the current user. Trying it out, and evaluating the performance difference might be the best way to decide.

Also, are you aware that the script must be web-compatible?

[Wim Decorte]

Also, are you aware that the script must be web-compatible?

Not web-compatible, but server-compatible if you are running the script as as a scheduled task on the server. There's a difference. Toggle your scriptmaker to "server" to evaluate the script and make sure it will work.

[bruceR]

Once global fields are set by a server script are persistent from that point on to all other users, including following server scripts and WAN or LAN users, next time they connect.

[David Nelson]

Now this is the apparent confusion I have been reading about. Thank you all for responding. But Bruce, Wim just said server-ran scripts behave exactly like a client. And your statement seems to go against that, since client values never stick in globals. So server-side scripts behave differently than client in this instance?

And Tom Elliot says here, https://fmdev.filemaker.com/message/71109#71109 mentions the same thing as Bruce as, "When a a server-side script sets a global field, the value is retained in the served file. Future client sessions will start with the global having that value, however for existing clients (i.e. those who opened the file before the script was run) the global's value will not be affected."

You all are top programmers so I assume I am still just confused. Any further clarifications would be most appreciated. And no, I can't test. We haven't bought server yet unfortunately and won't for another six months or more.

[bcooney]

David,

I believe the best way to think about globals is as session-specific values. Yes, their values may not be null on file open, but then, what are the values (as Bruce points out, the "default" global value may change each time a server script runs)? So, I would suggest explicitly setting the global values (I have a subscript that is called in my File>Open). Server runs File>Open with each server schedule. So, it'll get its global values, just as a client would.

Barbara

[David Nelson]

Hi Barbara, thank you for helping. I am trying to establish basic principles of understanding about how server-ran scripts work and how they might be different than client.

Then the phrase that everyone says about needing to unserve a file to set the global value to a new value is incorrect from what Bruce says. I should be able to let a User run a script (server scheduled script or web script) and set a global and it should stick and all users from that point on will see that value when they open from then on. That is different than if a client runs a script whereas their value is gone after they close. And yes, I set globals in startup script on file open. But if an admin needs to change a global value, why take it offline to do so if setting by server will handle it so that value persists to all users from then on?

Bruce appears to contradict Wim on Item #2 above. I have spent probably 40-50 hours researching FileMaker website info and I cannot find the answers. And 3-4 forums all contradict each other (at least it seems that way). Surely I can't be the only one who finds this confusing? I do not want to say I believe one person more than the other. I would rather suspect that I still lack understanding of the issue. I would bet pretty betty that I am not alone.

[bcooney]

Globals are typically populated by setting them to the value in a corresponding Preference record field. The Preference table has only one record.

"Let a User run a script"...Bruce is saying that when a server scheduled script runs, the default global values are updated if the script indeed sets those values. As if you took the file down single user, changed a global, and rehosted the file.

The admin should never need to change a global value. They should change the value in the Pref field. Users will receive this new value the next time their globals are set (File>Open or sometimes I put an update globals in the Main Menu nav so that all global refresh everytime a user goes to the main menu).

Users cannot run server schedules, btw. I think that is the key to your misunderstanding of their replies.

[David Nelson]

Forgive me, but this thread is not about how to administer a preferences table or set a global. And you just also contradicted Wim in the behavior of server.

I give up.

[bcooney]

Here's something to think about. I have a server script that sends emails. It is scheduled to run every 5 mins. It Finds for all email records where flag_queued = 1.

So, when a user creates an email record, and clicks "Send" all they are doing is setting a flag=1. The server script scoops up these records are processes them further.

Does that help? Here's an article from Agnes Riley on server-side scripting that may be helpful.

I suppose I've lost track of your question and goal.

[dansmith65]

David, I was also confused about the conflicting information I saw recently about how global field values acted when set by a script run on the server. As you said, bcooney and BruceR both contradicted what Wim said.

However, I have access to FileMaker Server, so I made a test file and got to the bottom of it. Here is what I found...

• A server-side ScriptMaker script, as defined here: http://help.filemake...ilemaker-server WILL modify the value of a global field, as if the file was not hosted, and opened in FileMaker Pro.
  
• A custom web publishing script triggered via an XML url, will NOT modify the global field. This acts like a regular client using FileMaker Pro to access a hosted database.
  

You can see how this works for yourself using the attached file. It uses a web viewer to trigger a script via the XML web publishing engine (which was another of your questions, David).

GlobalTest.zip

[comment]

• A server-side ScriptMaker script, as defined here: http://help.filemake...ilemaker-server WILL modify the value of a global field, as if the file was not hosted, and opened in FileMaker Pro.
  

Dan, have you tested if the modification persists beyond the "hosting session"? IOW, if you unhost the file and open in it FileMaker Pro, is it still there?

[bcooney]

Although I do appreciate the academic need to confirm default global values, I stand by my assertion that they should be set by script for each session (usually from a PREF table).

[comment]

I stand by my assertion that they should be set by script for each session

I am looking at your previous posting in this thread, but I don't see that you have provided a reason for your assertion there either...

[bcooney]

I suppose my response was not clear. When I said, "Yes, their values may not be null on file open, but then, what are the values...?" I was suggesting that it is more reliable to set a global to the value than to rely on a default value.

[comment]

Why do you consider a value stored in a global field "less reliable" than a value stored in a non-global one?

[LaRetta]

Barbara, David is not asking for answers to a specific question. He is trying to understand how server might differ from client in MANY aspects. He even said he uses a Preferences table. The questions go beyond just one specific need here ... it is the need to understand the underlying behavior. You say it is 'more reliable' but that means in some instances it is not. If true (and I do not doubt you) then it is important to understand WHEN it won't be and WHY it varies.

The woman cuts the ends off of her ham before she bakes it. Asked why, she said, "my mom always did." Asking mom, she said, "MY mom always did." Asking grandma, she said, "because it wouldn't fit in my oven otherwise." David is asking why we cut the ends off. I'm feeling frisky this morning!

Comment phrased it a bit more concisely ... LOL

[bcooney]

LaRetta,

Funny you mention the "ham" story. I had heard this story, but it was "meatloaf." In fact, I often tell this story to customers, since in gathering requirements, many times processes are examples of "meatloaf." In fact, they walk around now saying, "but isn't that really just meatloaf?," lol.

OK..back to topic. I have always thought of global values as session specific and do not consider them as equals to non-global fields. I don't take a file down single-user and set globals. I don't even do that in the commercial runtime I developed. I always set global fields. (I don't use global calcs, as I've seen flakey behavior with them.)

So, yes, comment, again I'm preaching my FM-learned lessons as "best practices." I'll preface everything with imho from now on.

[LaRetta]

I don't take a file down single-user and set globals. I don't even do that in the commercial runtime I developed. I always set global fields. (I don't use global calcs, as I've seen flakey behavior with them.)

Global calcs are completely dependable once you understand the principles behind their behavior and so are global fields. It isn't a matter of being 'dependable' but rather understanding their nature. Once you understand a principle, you can proceed without worrying that a behavior is 'flakey' or 'less reliable'.

That's all we are trying to achieve here ... understanding the nature of a thing for David. This thread clearly is addressing principles and not one specific, except to use a specific to attempt to identify the principle. :grad:

[comment]

Over the years (my, how the time flies...) I have seen many rules and recommendations being circulated in the FM community. Some of them are perfectly valid thumb rules - e.g. "always print from the child table". Others - too many others - turned out to be entirely baseless, mostly results of a misunderstood experience. If I wanted to put it dramatically, I'd say that generations of developers have cheated themselves out of benefiting from some very useful features, due purely to prejudice (repeating fields, anyone?).

Barbara, it just doesn't befit your hard-earned status in this community to make a non-specific statement like "I've seen flakey behavior with them". There's nothing one can do with this, except panic. I mean, if Barbara thinks they are flakey, I'd better stay away from them. IMHO, if something seems flakey, it needs to be investigated. It could be a bug (rare, but not unheard of) or a simple misunderstanding (alas, too common).

I think LaRetta said something very similar, but it's on previous page now so I can't be sure. :hmm:

[dansmith65]

Dan, have you tested if the modification persists beyond the "hosting session"? IOW, if you unhost the file and open in it FileMaker Pro, is it still there?

Yes, I did test that, and the value did still persist.

Barbara, I do think global fields that don't have their values set on file open have there place. I use that type of global field for interface graphics, for example.

[Wim Decorte]

And you just also contradicted Wim in the behavior of server.

I give up.

I don't think so. I said that users can run a script directly (through a URL), but they can not run a schedule directly. It may be a fine distinction but a schedule can be more complex than just a script: it can have OS level scripts before and after running the script.

[bcooney]

@Wim - In my reply (#10) I tried to call attention to "I should be able to let a User run a script (server scheduled script...)" and how this is where the misunderstandings, imho, began. Users cannot run schedules.

@Michael, I take your post as a left-handed compliment. Perhaps you are correct, and if "Barbara" doesn't trust it then I shouldn't. I should not be so flip in my replies. Perhaps I'll start an investigation of global-calcs rather than just avoid them.

@Dan - and so if the company logo changes or you wish to change the graphic you use for delete, you take down the file, sub the graphic, and rehost? Why not populate from a pref table?

[bruceR]

@Michael: "I'd say that generations of developers have cheated themselves out of benefiting from some very useful features, due purely to prejudice (repeating fields, anyone?)."

I agree, kind of. I suppose it may be prejudice in some cases. But in other cases, just lack of awareness. Seems to me all of this points to several things, including:

1. Documentation as supplied by FMI. Where's the manual?

2. Tribal knowledge

3. FileMaker (and databases, interface design, etc) is a very very large topic. It isn't too surprising that there are a lot of variations in the completeness of understanding. What are the things we can do about it?

4. Sharing our best work. Many people, and certainly you, contribute very useful observation and simple sample files. But we have few good, deep, comprehensive shared examples of complex high quality work. Not too surprising, are highly experienced developers going to show their best recent work?

5. Repeating fields: I would love to see an extended discussion of repeating fields and how they can be used effectively.

[LaRetta]

@the Universe - and in some cases, when faced with something strange, folks just figure ways around it using a different method instead of taking the time to understand why it was breaking. I too would love a detailed repeating fields discussion. I honk every time I see repetitions used in cool ways.

[dansmith65]

@Dan - and so if the company logo changes or you wish to change the graphic you use for delete, you take down the file, sub the graphic, and rehost? Why not populate from a pref table?

ok, I give. I think I agree with you on this now. I realize that the only reason I do it the way I do is that it hasn't bitten me yet. In other words: I haven't had to update a graphic on a hosted database that I wasn't able to take offline for updates.

Do you set these graphics on file open, though? Is there much/any of a performance hit in doing this? How about on FM Go?

I'm thinking that a "system preferences" table to store the image, and a server-side script to update the global fields when necessary may be a better option than doing it when the file opens. Of course, this isn't appropriate for all global, there may still be user-preferences that should be loaded on file open.

[bcooney]

@Dan - Yes, I set graphics on file open. I can't tell you about performance hits, since that is the only way I populate globals. Many systems that I work on are 24/7, and so taking it down isn't an option.

@Bruce "But we have few good, deep, comprehensive shared examples of complex high quality work." -- so true! That is why I appreciated PauseOnError, and love reviewing the code of top developers.

Many novice questions here present a challenge to me. I see where they might be going, sometimes before they do, and sometimes answer with what may seem to be an over-engineered technique. For example, popup menus to populate foreign keys (you'll outgrow those, typically); multi-keys vs. join tables, custom value lists vs tables with IDs and values - and the biggest of all -- an organized approach to the relationship graph. I do feel that if a novice saw a system with 100s of scripts, 100s of layouts and a relationship graph with 50+ Togs, 4 plugins, ESS, etc., perhaps that would give them a better sense of why sometimes the quick answer and approach isn't always in their best interest.

[Ralph Schwegler]

Here's something to think about. I have a server script that sends emails. It is scheduled to run every 5 mins. It Finds for all email records where flag_queued = 1. So, when a user creates an email record, and clicks "Send" all they are doing is setting a flag=1. The server script scoops up these records are processes them further. Does that help? Here's an article from Agnes Riley on server-side scripting that may be helpful. I suppose I've lost track of your question and goal.

Hello Barbara

I couldn't open that article. is there a new place for it?

cheers

[David Nelson]

I read the article by Agnes Riley and got excited for a moment. She is good writer but it just doesn't provide enough details and it is way too short to go into understanding it. I really appreciate everything you all offered on this thread. I believe every one of you and most of you I follow throughout the forums and I hold the greatest respect for each of you. I understand preferences tables and setting globals on startup. I wasn't looking for an answer to one thing.

But now that I understand there are more ways to 'run a script' and that it caused confusion, I think I can ask one detailed question and the answer will give me the principle I am trying to pin down (which is: can scripts evaluate or behave differently depending upon how the script is ran; now realizing there are more ways than regular user or scheduled script"? If I can find out which method of running a script might solve the question asked in this new way then I can go study that specific thing. As an aside, right now I have regular fields in preferences and global calculations to make their values available. It works really well. But again, that isn't my reason for asking. Please allow me one more try with a single question:

Can a User at their computer click a button to run an FM script or VBScript/AppleScript (using Send Event?) in a served FM file (version 11 windows/mac) and cause the value in a global to change and stick - immediately seen as changed by all users, value remaining even for other Users when they sign on - and until it is changed again either by taking it off line and manually changing it or by running this process again? Is there any way at all?

If I didn't know I wasn't stupid, I would feel stupid for even asking.

[dansmith65]

Can a User at their computer click a button to run an FM script or VBScript/AppleScript (using Send Event?) in a served FM file (version 11 windows/mac) and cause the value in a global to change and stick...

Yes, but not a regular button. The button must be in a web viewer, and the server must have XML custom web publishing enabled. Like in this file:

No, see this post: http://fmforums.com/...post__p__383783

... immediately seen as changed by all users ...

No. Other users will not see the change until they close the file and open it again.

... value remaining even for other Users when they sign on - and until it is changed again either by taking it off line and manually changing it or by running this process again? Is there any way at all?

Yes, see link above.

Edited March 14, 2012 by dansmith65

[David Nelson]

Wow. Now to understand what I am seeing and how to use it. Thank you. I do not know how I could have missed it the first time around. I appreciate you sticking in there, Dan.

Do I always have to create a new record? If I disable the new record portion, it doesn't change the timestamp. I can't test this yet so I will just trust that it works. Can you say a bit more about how it works? So once this file is served (for example), a user can run this script and it will change the global and it will stick (although users won't notice until next time they sign on. You covered it very well!

And this should be stickied somewhere for everyone to see so all the people asking can know about it. Why aren't people jumping up and down? I know I have read probably 20 requests for something like this just within the last year. Way to go, Dan! :waytogo:

[dansmith65]

I'm glad I could help!

Do I always have to create a new record?

You can delete the new record script step; that was just a way of confirming that the script was run via different methods.

Can you say a bit more about how it works?

I don't know what else to say; I thought I have explained it pretty well by now. What are you still unsure about?

[Fitch]

Yes, but not a regular button. The button must be in a web viewer, and the server must have XML custom web publishing enabled. Like in this file: http://fmforums.com/...post__p__383783

You just contradicted the post you linked to. As Wim (and you) said earlier, when you run a scheduled server script, the global sticks. When you run a script on the server via URL, no stick.