I've confirmed this in the retail release of FM13 so I think I'll submit a bug report.
What happens if you set script S to run with full access?
I was able to reproduce the issue following the steps you outlined and forwarded your post to product development. If any further information is required I will follow up with you.
Thanks for that, saves me trouble of a duplicate post on the public forum.
Ch0c0halic: Unfortunately Running the Script with full access privileges doesn't work. Thanks for the suggestion though.
We've encountered this too, Perform Script On Server does not seem to be able to open a file other than the one that is calling it. However, there is a kink in this one:
In training we were told that when invoking Perform Script On Server, the instance that is created has none of the user's state information, such as open databases, or current context etc.
However we have a case where just opening the file that we are working on, and calling perform script on server, the script fails because it is trying to access data in another database file. Bug. BUT. If the user then switchs to a layout based on a table occurence from that other file, changes back to the original layout, and invokes Perform Script On Server, it succeeds! This should not be case if the PSOS instance inherits no state information. Very very weird.
I seem to have run up against the same road block. Any updates from FM?
I am pretty sure this was fixed in server / pro 13.0.3. If I get the chance this week I will run my tests again.
I can see how you could assume that, but alas I am on 13.0.4 and still no joy. Perhaps they want that we should buy a sync too from a premier partner?