rivet Posted February 28, 2014 Posted February 28, 2014 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
Wim Decorte Posted February 28, 2014 Posted February 28, 2014 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.
rivet Posted March 1, 2014 Author Posted March 1, 2014 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.
Recommended Posts
This topic is 3919 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now