To answer the last question first, I would think that you could host the file from one computer using pro and then test this script from a different computer using FileMaker Pro as a client to connect to it, but I haven't tried it so you'd have to try this for yourself and see if it worked.
I would expect some improvement but at the possible cost of slowing down system responsiveness for other clients as the server is now using resources to perform this task instead of a client machine. And since this is a very new feature, there's not a lot of data to tell up how well this will work n a given situation. You'll need to test and see what you get.
And please check every step of such a "perform on server" script very carefully for server compatibility. There are a great many script steps that simply are not compatible when you use either FileMaker Server to schedule a script or this new Perform on Server step to perform the script. Import and Export scripts are especially challenging as they show as server compatible, but they have severe limitations on what you can actually do when the script is performed on the server: http://help.filemaker.com/app/answers/detail/a_id/12067/kw/server%20schedule%20import
I did contact FileMaker sales directly with this question and they did suggest that I would see a notable improvement in speed. I will need to pour through the scripts as you said, though it is mainly comprised of "Go to related record", "Set Field" and "Set Variable".
As for setting it up on Pro for testing, I found this:
Setting the variable looks like a bit of a challenge though given that the client's variables are ditched once you start to perform the script server-side. I am also not clear on how this would work with Global values.
This more or less is looking to be a big scripting dance to solve speed issues and makes me wonder if this project, which is a prototype to begin with, needs to be taken to a true web-application sooner than planned because all these workarounds are turning it into an overcomplicated rat's nest that is going to be tough for anyone but myself to make sense of when it comes time to re-write it in web-app form.
I will keep this updated with any findings. Looks like the best way to figure this out is to setup a server locally as we are currently using Triple8 - so those findings may be delayed.
I had read that entry, but had forgotten the "must be on server" specification. I think I'd test that claim with the setup I described any way. (I currently only own one copy of FMP 13 so can't test this myself at the moment...) Sometimes the documentation isn't correct and it'd be darn useful if we could test it in that fashion. (But now that I think about it, it wouldn't surprise me to find that you have to have server.)
You can pass data to the server script via a script parameter. Here's how I sometimes pass multiple items to a subscript in a single parameter:
I use an expression such as:
List ( Field1 ; Field 2 + Field 4 ; Field 5 ) or whatever where each listed value is a different value to pass to the script. Then I start the sub script with a set of set variable scripts that use GetValue to extract each listed value. Not only does this set up a group of variables for use in the script, it tends to "self document" the values passed as a parameter.
SetVariable [ $FirstParamValue ; value: GetValue ( Get ( ScriptParameter ) ; 1 ) ) ]
The main limitation of this method is that list omits any listed element that evaluates as "empty" or null. so all the listed values except the last one must evaluate as a non-null value (even if just 0 or a space character) or the Steps with GetValue will put a value in the wrong variable.
If that's a possible issue, then I use this type of expression:
"Let ( [ $Variable1 = " & Field1 & "$variable2 = " & Quote ( Field2 ) & "] ; 1 )"
and then use:
SetVariable [$Dummy ; value: Evaluate ( Get ( ScriptParameter) ) ]
$Dummy just receives the value 1, but the Let function sets the listed variables to values for me. ($Variable1 shows how to assign a number. $Variable2 shows how to assign text.)
That is a creative approach to this. I will give that a go and hopefully script parameters are passed on to the server.
This was incredibly effect.
Clicking the portal row button on an inventory item to be added to the job triggered a 'local' script that showed CustomDialogs. The ScriptParameter on this button also created the value list of local variables. When is comes time to run the long script on the server, the RunScriptOnServer function is used and these variables are injected into the server-side script by setting the ScriptParameter as "Get (ScriptParmeter)
As you suggested, I used the GetValue function to set each variable in the script to it's corresponding line in the ScriptParameter
With this approach when accessing the database remotely this script runs nearly as fast as it would if it were local. The difference is approximately 20-30x faster than execute this entire script on the client side.
There are a few problems that still need to be worked through, including refreshing the client-side portal to reflect the added record. This currently takes significantly longer than running the script. I've tried a "natural" refresh, and a few other refresh script steps to no avail. The window essentially freezes for about 15 seconds.
Just as a note, I am running this database on a third-party virtual server which may be responsible for some of the original sluggishness of this script.
Is this a Filtered or Unfiltered portal?
The LineItem record show up in a portal that wants to be filtered, though I have removed that functionality in the quest for speed. The layout this happens on contains a three-part tab and the visible tab has two portals - a search portal to inventory and a lineitems portal. I have removed the filters on both portals as well but still running across the issue.
I am going to try switching this whole setup to a list view unless there is another suggestion?
There can be issues getting a filtered portal to update even if you are not using this new option. I was just checking to see if those issues might be a factor in what you are dealing with.
You made a general mention of trying different methods to refresh things. Can you provide a detailed list of what you tried? If nothing else, it may help others who are bound to encounter the same issue.
There weren't any issues with new records showing in the portal when the script was run client-side, but the script took too long to execute as I had mentioned before. As for the refresh methods, I used a "refresh window" script step as well trying it's various options. I also tried the new "refresh object" step out of curiosity. These were still unacceptably slow from a user's view.
The most recent attempt was to use a slide control where one panel is the LineItem portal and the other is the Inventory portal. This was semi-effective in the sense that it only required a single refresh after adding a few items rather than for each item. The refresh occurs automatically (without a script step) when the panel is slid back to the LineItems view. This was the quickest in the sense that it doesn't happen between every item, but from a user perspective it is still unacceptably slow.
An additional concern with the "perform script on server" approach is the amount of processing required on the server to pull this off. I often find that it is best to look at things at radical extremes to find their flaws and, if I am understanding the "perform script on server" script step properly, I see a possible issue when multiple users - even if just two - add an item at the same time. I am not certain if the server would complete both script requests simultaneously or wait until the first request is completed before starting the second one. While it is only a few seconds to run the script, if a user did need to wait for a prior script request from another user to complete, this has the potential for creating a massive backup if there are "perform on server" script requests being submitted faster than the server can perform them.
If, however, the server sandboxes each user's "perform on server" request there is no longer a multi-user queueing problem and the script itself prevents a user from submitting another execution request until the current one has completed which avoids this issue completely in a sandboxed environment - IF that's how the FileMaker Server 13 handles the "perform script on server" step, which I suspect it doesn't.
Moving on to another related discovery, the original version of the script in question (which is fully executed client-side) performs extremely fast on WebDirect and because it is client-side it doesn't require a window refresh to show the newly created record. Unfortunately, however, this seems the be about the only time I would use "fast" to describe WebDirect.
As far as I can see, my only remaining option is to try using a list view for LineItems and Inventory in hopes that the newly created server-side record will populate more efficiently than it does in portals.
One "longshot" that you might try:
If your relationship is:
MainTable::__pkMainTableID = PortalTable::_fkMainTableID
see if any difference takes place when using this relationship:
MainTable::__pkMainTableID = PortalTable::_fkMainTableID AND
MainTable::__pkMainTableID x PortalTable::_fkMainTableID
The relationship will function much the same as your original relationship (except "allow creation" is no longer an option) but the use of the X operator does have a known effect on how a portal updates. (It's a trick used to get filtered portals to update without a script.)
I have my doubts that it will work, but it's worth a quick experiment...
And from my experience with how server scheduled scripts work, I think you are correct to be concerned about possible server side bottlenecks if multiple clients kick off server side scripts at the same time. I'd expect Server to perform them one at a time with the additional requests "queuing up" to wait their turn for execution. This is a strong argument for using the fastest hardware you can get if your design leans heavily on this new feature.