You probably need to split that script into two.
script one: Open URL...
script two: all the rest.
Run script one. Now the other db opens and runs on open script. This script calls the original db, to run script two. You might use Open URL... with parameters to call the script in the original db.
Hmm, but how would I then pass the script result from the connector db on to the second script in the deployed db? If I'm understanding correctly, in your scenario, the last step in the connector db's script would have to be Perform Script (deployed db script 2). I thought that in order to pass the script result on to the next script, the last step had to be Exit Script [Result: x]. Using Exit Script in this way is all very new to me, so perhaps I'm just misunderstanding how it works.
I think I see your confusion. Yes, you do need Exit Script (ScriptResult) to pass something back to the calling script. But you also need to have a calling FileMaker Script to which the result is returned.
From what I saw in your snippet, you didn't call a subscript with Perform Script (remote script name from Connector file) in your deployed database. You seem to be expecting that the Connector file is aware of the existence of and has some connection to the deployed file. It doesn't.
The most current way to pass information between scripts is like this:
Script: "Run Connector Synch Script" in deployed file
Set Variable ( $ScriptResult ; Get ( ScriptResult) )
...do the rest.
This would require a correct reference in File>Manage>External Data Sources in your deployed file.
My guess is that's the hard part for you to do, since that Connector file could be in different places on different devices. Is that right?
If so, then maybe the best thing to do is actually to make a new post with a more refined question and a new subject line (e.g. 'passing data between local FMGo files withOUT a file reference' ). I have a few ideas on how to make what you want happen, but there may be better answers from folks who have actually done this.
-- Drew Tenenholz
Actually, I just realized that I can access the global field that I'm trying to set in the deployed database from the connector database. So instead of trying to pass the variable from the script in the connector db to the deployed db, and then set the global field in the deployed db, I've just set the global field from the script in the connector db. Problem solved!
Also, it looks like I now have my very first fully functioning synchronization process built from scratch. I only need to add a one-way deletion process, but that shouldn't be too hard compared to what I've already done. Hooray!
Glad you have a working solution. A global field was one of my ideas, but I didn't know if you wanted to try that.
Have you been able to test that once you remove the local Connector file on the device and run the entire process from the top that it actually 'plays through'?
You could also employ the same method you did to start the synch; using an Open URL() step in Connector to run a script in the deployed file and send along a script parameter that contains the timestamp data you wanted. Then you can use Get (ScriptParameter) to get what you need in the deployed file.
There's probably a couple other ways to do this as well.
Yep. I have the deployed file with the connector enclosed in it on an iPad and had it run through the entire process start to finish. I'm sure there will be some tweaking needed along the way as I do more testing, but at the moment, it runs flawlessly, whether there are records to be updated or not. I've also tested it under several conditions that would cause it to error out to make sure the scripts handle the error correctly, but I do need to do more testing in those scenarios before I can call it done.
Your suggestion for using Get (ScriptParameter) makes sense, and I see now that that's what Malcom was suggesting as well. I just didn't quite understand what he meant at first. That would certainly also work in my process.
I wasn't able to have the deployed script call a script in the connector database because the deployed database can't have any file references that ultimately lead to the hosted database. If the deployed database is set up with the connector as an external data source, then the connector may be forced to open and remain open - which then forces the hosted database to open and remain open. That could prove problematic if the internet connection on the iPad was lost. At the end of the process, I need to be able to close both the hosted database and the connector database so that the user can continue working if their internet connection is lost.
A script called by URL can pass parameters to the script. This is the same as passing back a result via Exit Script. The difference in this case is that you are not in the middle of a script so you would not test for get(scriptResult). The script that has been triggered would test for get(scriptparameter).