Perform Script on Server - global fields

[charlest]

A couple of questions...

 

I have two tables Customers, and Customer Employees.   Customers is the parent table to Customer Employees.  On a layout based on Customers there is a portal of Customer Employees on the right hand side, and fields which contain more details about a given Customer Employee on the left hand side of the layout. By clicking on a Customer Employee in the portal, a global field in the Customers table is set to the primary key of the Customer Employee which creates the relationship that displays the details about that Customer Employee.

 

When creating a new Customer Employee record, a set of global fields are passed to the server through the script parameter as a list and then parsed by the server.  I want to have the primary key of the new record created to be the new value in the global field in the Customers table so the user sees the details of the new record created.  It appears to work simply by having the server set that value, however will this work with multiple users creating records simultaneously?  Will each user get the value in his global field for the record he just created, and only that value?

 

Secondly,

 

I understand that a PSOS cannot be called from a script running on the server.  Does that also imply that a field with a modification trigger cannot run a PSOS if that modification results from a different PSOS?

 

Thanks.

[Lee Smith]

Automatic message

This topic has been moved from "FileMaker 13 General Discussion" to "FileMaker Server 13".

[Wim Decorte]

Global fields that are set as part of a PSoS session will not be visible to the user that called the PSoS, PSoS is its own "virtual" user session, it does not use the user's session.

 

You can have the PSoS script return a result and capture that back in the client's session and set a global there, that would do what you intend to do.

 

 

I understand that a PSOS cannot be called from a script running on the server.  Does that also imply that a field with a modification trigger cannot run a PSOS if that modification results from a different PSOS?

 

 

That is very confusing.  A trigger can call any script it wants, including PSoS execution.  But a script running inside a PSoS session can not call another PSoS.

 

But since the PSoS session is an explicit scripted action anyway, why would you want to rely on a triggered event to do something, why not let the script do things explicitly?

[charlest]

I was getting client global fields to evaluate correctly on a PSOS script, which caused me to question if I understood correctly that they are session dependent.  (I then realized I had selected perform script...not perform script on server... let me wipe the egg of my face.)

 

I had not thought of using the return script result.  Thanks.

 

As for the second question...

 

Right now the client script changes an existing value and the PSOS logs the change that just occurred with an on modification trigger.  I am wanting to now have a PSOS change the value, and was wondering if the logging would still occur as an independent PSOS.  I could build into the script the logging, but if there were no issues with calling the script with the trigger I could leave the logging as is.

[charlest]

Having tried several different routes, I have found the results inconsistent and will abandon this and figure some other way.

 

Thanks for your input

[bcooney]

Why do you need PSoS to accomplish this functionality?

 

User clicks a New Employee button (perhaps just above the portal of existing Customer Employees). Script that create new employee captures $customer_id , goes to customer_employee layout, create new record, populates the foreign customer_id and sets sets a global in customers to the new customer_employee_id. Returns to original layout. Now the fields to the left are editable.

 

Better yet, explore popovers and the magic key technique.