Hi there,

 

I'm running a script on fm13 server that sets a value in a global field.

 

the issue is I need to pass that variable back to the client when the script completes.

 

Is there a way to do this?

 

the reason I'm doing it this way is that I'm looping through a found set and setting the global variable and it's really slow if I do it on the client machine.

 

Mark 

Mark --

 

Perhaps you could pass the global field's value back to the client as a script result.

 

-- Tim

the reason I'm doing it this way is that I'm looping through a found set and setting the global variable and it's really slow if I do it on the client machine.

 

Hi Mark,

 

You'll still need to pass the result through Exit Script[] but I wonder, since you are now using 13, if you can't use the new summary List Of to gather the values instead of looping.  It's great for gathering IDs and is very fast.

Hi there,

 

Thank you for your suggestions.

 

LaRetta - I think your suggestion may actually solve my dilema - as that's exactly what I'm trying to achieve by running it on the server. I'll have a play with it and see how it works.

 

Back to the original question (I am still curious how to pass a global field value back from server to client) I had a quick look at the exit script step - and I'm not exactly clear how I would pass the result of the global field from the server to the global field on the client machine. 

 

If I pass the global value from the server through the exit script step then the script stops running right? how does it pass it into the local global field?

 

Mark

LaRetta,

 

Your suggestion worked perfectly - I wasn't familiar with this new feature but it worked wonders for what I needed. I can now build the list in no-time and no longer need to perform the operation on the server.

 

Thank you.

Just coming back to this old thread, as I still have a need to pass a variable from a server side script back to a client side script.

 

I have a script which starts as a local script, ie. it performs a number of script steps if it's running on the local machine

It then Calls itself using the "Perform script on server" and performs a number script steps on the server

When the server script is complete it continues to run a number of script steps on the local machine to complete the overall script

 

I need to pass a variable from the server back to the client during that last step.

 

Is this actually possible?

Did not the first suggestion (to use the script result) work for you?

Hi Comment,

 

To be honest I'm not familiar with script results and passing them.

 

I'll do some digging to see how it's done.

 

Mark

It's really simple:

 

One script exits with the "Exit Script[ "your result here" ] script step

 

The calling script captures it:

 

Set Variable[ get(scriptresult) ]

I need to pass a variable from the server back to the client during that last step.

 

Main script runs:

do something then run server sub-script

...

server script runs:

... does a find and then

Exit Script [ ListOf:  your summary list of ids ]

 

back at your main script it continues

 

Set Variable [ $$ids ; Get ( ScriptResult ) ]

 

LOL, hi Wim!!! :-)

Edited March 2, 201510 yr by LaRetta

It's really simple:

 

One script exits with the "Exit Script[ "your result here" ] script step

 

The calling script captures it:

 

Set Variable[ get(scriptresult) ]

 

It's actually even simpler than that: the Get ( ScriptResult ) register is available at all times and can be used directly, without capturing it into a variable. The only reason to copy it into (another) variable is if you're going to call another script that will overwrite the Get ( ScriptResult ) register.

Interesting.  When I read Help on Exit Script, it says:

 

If the optional script result is specified, the script result is returned and stored in the main script until another sub-script that returns a value is called. The script result gets deleted when you exit the main script. The script result can be stored in a local or global variable for later use.

 

So we may be able to use it directly but we must be careful to use it before that sub-script's parent script exits or pass it again in the parent's Exit Script (or as script parameter) to use in another script.  Is this correct?  Or are you saying that Get ( ScriptResult ) survives in the air and is available ANYWHERE if we ask for it (until it has been over-written by another)?

 

And good morning!

It's actually even simpler than that: the Get ( ScriptResult ) register is available at all times and can be used directly, without capturing it into a variable. The only reason to copy it into (another) variable is if you're going to call another script that will overwrite the Get ( ScriptResult ) register.

 

It's a preference borne out of troubleshooting efficiency.  If you capture it in a variable you get to see the result right there in the "Current" view of the data viewer without having to switch to the "Watch" list.

 

There is no penalty in not doing it.

Or are you saying that Get ( ScriptResult ) survives in the air and is available ANYWHERE if we ask for it (until it has been over-written by another)?

 

Get (ScriptResult) survives as an object for as long as there is a script running. When the last script in the stack has run out, Get (ScriptResult) goes poof.

 

I say "survives as an object", because the contents of the object may change during the course of its lifetime. Any script that exits with an explicit result will overwrite it. So the answer to your first question is yes: you must either use it before the calling script exits, or pass the value to some other object (e.g. another script, a global variable, a field...).

 

And good morning to you too!

There is no penalty in not doing it.

 

Ah, but there is a penalty in doing it: it takes up RAM. Could be a considerable amount of RAM too, for instance in LaRetta's example.

 

 

If you capture it in a variable you get to see the result right there in the "Current" view of the data viewer without having to switch to the "Watch" list.

Right. This is a part of an ongoing discussion regarding whether to keep the scaffolding. IMHO you should - at the very least - disable the step once the script goes into production. And of course, it goes without saying that the script itself should refer to the original register, not to the copy.

I was wrong to use:  

Set Variable [ $$ids ; Get ( ScriptResult ) ]

I didn't know what Mark wanted to do with the result so I just winged it ... and not very well either, by just plopping it into a global variable for his easy access.  I should have just put "... then do what you want with the script result."  :-)

 

But even if using a script variable, it would have taken resources for the duration of the script, right?  I agree 100% about leaving scaffolding.  I disagreed on one other instance but now I'm going to go change it as well.

 

Ah, but there is a penalty in doing it: it takes up RAM. Could be a considerable amount of RAM too, for instance in LaRetta's example.

 

 

 

 

That's an edge case.  But even accounting for that I really don't see how storing the get(scriptresult) in a variable would ever present a performance issue.

The benefits outweigh the remote possibilities of a penalty.

 

Right. This is a part of an ongoing discussion regarding whether to keep the scaffolding. IMHO you should - at the very least - disable the step once the script goes into production. And of course, it goes without saying that the script itself should refer to the original register, not to the copy.

 

I don't agree in this case.  Leaving it in place carries not penalty.  If it does it will be because the deployment hardware is very marginal to begin with and there will be may other issues to fix before this one.

 

The troubleshooting benefit is enormous.  The penalty is almost not measurable.

That's an edge case.  But even accounting for that I really don't see how storing the get(scriptresult) in a variable would ever present a performance issue.

The benefits outweigh the remote possibilities of a penalty.

 

I am not entirely with you, I am afraid. You don't see the reduction in available RAM as affecting performance?

 

And what are those "benefits" you refer to? So far you've mentioned only one - and that's watching the variable's value during debugging. Well, that benefit can only be enjoyed while debugging; leave the variable in and it will continue to eat your RAM every time the script runs. I feel kinda foolish having to explain this - isn't it a no-brainer?

Well I see both sides.  It certainly makes sense to at least disable it once testing is done but it is sure simple enough to add it even in the middle of debugging so leaving it still isn't helpful, particularly when the script will probably rarely be accessed - at least compared to the number of times a User will run it.  And I know that I've seen variables left in scripts and I had to wonder what was the purpose, thinking it must be used later on.

 

It would be helpful then, if you DO end up leaving it, that you add a // TESTING at the end or as a comment. 

Also, the variable WOULD be measurable, depending upon the script result, right?  As I had used it, it would be very large.

I am not entirely with you, I am afraid. You don't see the reduction in available RAM as affecting performance?

 

I don't.  I have yet to see the increase of RAM usage for a few variables create performance problems on either the server or client.  Unless the deployment is marginal in the first place - which is a different problem to solve.

 

A large portion of my business is rectifying troubled solutions.   RAM usage of variables has never ever proven to be an issue.

I don't.  I have yet to see the increase of RAM usage for a few variables create performance problems on either the server or client. 

 

Lucky you. I can sometimes sense the impact of just having copied a large amount of text.  Mind you, I am talking about the overall system performance, not Filemaker in particular. And my system certainly scrapes the "marginal" considering all I make it do.

 

Still, if there were a person I would expect to say "every little bit counts", it would be you before me.

Just wanted to chip in and say thanks for taking the time to provide such detailed responses.

 

Implementing now using variable  (just for better visibility and easier tracking)