I write this with a little embarrassment at the solution to a problem I had. Earlier this week I renamed a server I’m using for GP2010 to prepare for a new network and improve my network naming conventions. I’ve changed server names before at clients and the steps and places you need to make updates are pretty straight forward, at least for vanilla GP. There are other complications when you get into web services and other things where the configuration is not strictly within the application.
I changed the server name and updated the obvious things but was still unable to log in to GP. I could log into SQL Server Management Studio just fine but couldn’t log into GP, even as ‘sa’.
For reference, here are what I call the obvious things to check and rename if necessary. I’m not including updating FRx or web products, just plain ol’ GP. If you use IP addresses to reference pathnames then often you are ok unless the IP address has changed. In my case I use UNC pathnames and had several places to update.
- Dynamics.set launch file – update the pathnames to shared reports or forms if applicable
- Dex.ini configuration file – update the pathnames to other shared items if applicable, like OLE notes, Letters etc.
- SQL server @@servername update – you need to run the relevant “add” and “drop” command to change the server name
- ODBC datasource – update the SQL server name, if using UNC pathnames
I changed all of the above, and continually banged my head against the wall trying to sort out why I still was unable to log in.
The “DOH” Moment!
I’m running a 64-bit operating system (Windows 7 in this particular machine’s case). I completely forgot that the ODBC shortcut you get to via Administrative Tools is 64-bit only. What confused me was there was a “Dynamics GP 2010” DSN already listed so naturally, I updated it, but still couldn’t log in.
GP requires a 32-bit ODBC DSN, and I had to open the 32-bit version of the ODBC setup window. If you’re reading this far and looking for this as well, on Windows 7 you can find it here:
C:WindowsSysWOW64 and it’s called odbcad32.exe.
Thank me later! 🙂
(originally posted on www.kuntzconsulting.ca, and migrated to this site in October 2017)