February 28, 201411 yr OS: Windows FYI SERVER13: 64bit CLIENT13: 32bit (some or all of it, not 100% sure, but definitely the script engine ) THE ISSUE: 1. creating a script in client to pull in from an ODBC source, the import step will only see the 32bit DSN 2. trying to run that script via server schedule, or via a client side “Perform Script On Server” step, would fail. SOLUTION: create a 32bit and 64bit version of you ODBC DSN and name them exactly the same With both connections named the same, server and client can resolve the connection
February 28, 201411 yr On server you only need the 64-bit drive-based DSN, but you are correct in that the DSN has to be named exactly like the one used on the client when the script was created and tested. There is no need to also create the 32-bit DSN on the server.
March 1, 201411 yr Author Good point I should have mentioned the configuration: My typical configuration is that the server is the only machine with an ODBC connection. I do not add ODBC connections to any of the client machines local or wide. Because of this, a client copy of FMP on the server is required to configure the scripts, which is why the 32bit connection is needed. While a client machine could have its own ODBC connection for script step-up, it might not be possible in a tighter security situation where connection to the external data source is restricted: – FMS and external data source are behind the same firewall – local FMS is the only machine whitelisted to access the external data source.
Create an account or sign in to comment