Does global field populated on the server appear for the user who ran the script on the client side?
I want to create PDF's on the server and have it drop into a global container that the user can then export.
For a file on FMS, a global field is specific to each user session. I assume from your brief outline that you mean a user to run a script which will create a PDF and place it in a global field and export it from there immediately, or at least within that session; this much will work. You need to realise, however, that the global field will be cleared when that user closes the file. If you need the pdf to be retained for future use you need to store it in a standard, not global, container.
I'm counting on the field being emptied when they're done. The purpose is on-the-fly PDF creation without the WAN hit.
Not to be thick but to confirm: A global on server will appear for that same user on the client?
Hmmm, by "populated on the server" do you mean that the PDF is created on the server using a Perform Script on Server script step? So the local client clicks a button, which calls Perform Script On Server which generates a file on the server and saves it into a global field, and then you want the local client to be able to access that global field?
If that is the case, then the answer is no. As keywords said, global fields are session-specific and scripts run as PSOS run on the server in a different session than the local user client and so information is not transferrable in that way.
I must admit to being confused here. @keywords says "correct", you say no. I understand how globals work locally. I was hoping that a global populated by a user in a given record on the server would then appear on that record on the client side.
I can understand your confusion. I don't believe @keywords understood that you were talking about scripts running on the server vs. in the client - I expect that he assumed that everything was being processed locally (he uses the terminology: "within that session"). When I saw his response, I thought I should clarify as I read your description differently than he might have.
From the FileMaker Help manual (FileMaker Pro 16 Help): "When a client connects to a hosted database, each client’s global field values are maintained independently from one another. This makes global fields useful as temporary storage locations for information unique to each client’s session, such as fields used for filtering portals or lists." (emphasis mine) Scripts run as Perform Script On Server operate in a separate session (on the Server) from the client session, so global fields are not shared between Server sessions and Client sessions.
One way that some people address this is to have a table with a regular (not global) container field where the server saves the field and then the local client session can retrieve the file from that field (and clear it, if necessary).
You should think of a PSOS as another client. Every client has their own unique copy of any global fields and variables. Global fields and variables are all local to the session so they are not available to any other sessions (clients).
Since you are discussing a global container the file in it will not be available to anyone. It will be discarded when the PSOS is completed and the session is terminated.
ONE WAY TO GET YOUR FILE.
I suggest you create a record in a (new) ‘file passing’ table. Use an auto enter serial number field and a container field. Create a new record and load the file into the container field in this new record. Record the serial number in a variable. When exiting the script pass this variable back to the calling script.
Have the calling script get the Script Result. Go to the “File Passing” layout and perform a find using the script results. Now you have access to the file. I also suggest that once you’ve moved this file to where it belongs that you delete this record. Otherwise the file will become bloated with unneeded files.
Good solution. I'll look into that.
However, it would be a nice feature to have the option to invoke. Nice way to easily use the server and ditch the data when done.
philipHPG wrote:I don't believe @keywords understood that you were talking about scripts running on the server vs. in the client - I expect that he assumed that everything was being processed locally
I don't believe @keywords understood that you were talking about scripts running on the server vs. in the client - I expect that he assumed that everything was being processed locally
Correct assumption. I was talking about client side scripts, not PSOS.
Retrieving data ...