How To Create An ODBC For Microsoft Dynamics GP 2010 | azurecurve

Azurecurve covers How To Create An ODBC For Microsoft Dynamics GP 2010

Error: Attempting To Log In From A Data Source Using A Trusted Connection | azurecurve

Ian Grieve fixes his Error: Attempting To Log In From A Data Source Using A Trusted Connection

That’s what happens when you don’t pay attention to setting up the ODBC!

Fun with changing a server name! - Kuntz Consulting

Kuntz Consulting digs into Fun with changing a server name!

Soon it will be so much fun we’ll have to sell tickets!

In Touch with Dynamics (GP): How to create 32 bit ODBC data sources for Dynamics GP from a 64 bit server.

In Touch with Dynamics (GP) digs into at How to create 32 bit ODBC data sources for Dynamics GP from a 64 bit server.

SQL Server DNS Configuration

Digging deep in the bowels of Dynamics GP, Mariano reminds us of the importance of a correct SQL Server DNS configuration.  I covered some items around this as well recently when it cause password issues at a client.

Weekly Dynamic: Dynamics GP Passwords, Case Sensitive Logins and ODBC Connections

Yeah, the title is a little weird. Here is the background. A client was moving terminal servers. Old server and new server were both pointed to the same Dynamics GP source. Users would log in to one terminal server and everything worked fine. When they logged into the other terminal server, GP would lock and their password needed to be reset. It didn't matter which terminal server a user logged in to, the first one they logged into worked fine, the second one hung and required a password reset to use that terminal server.
I know, what does the terminal server have to do with a GP password?
Well Dynamics GP uses the User ID and the server name in the ODBC connection as part of the hash when encrypting the user password for the first time. In our case, one of the terminal servers had the SQL Server as a fully qualified domain name and one just had the server name. So the weren't exactly the same and it broke the ability to decrypt the password.

This is also why user logins are case sensitive. The ASCII characters are different for upper and lower case letters so different information is passed when encrypting upper case vs. lower case passwords for the first time.

To solve our little problem we made both server names identical in the ODBC setup and then we reset the passwords of the affected users.

Huge thanks to Rob Mitchell of I.B.I.S. for the background behind this. He is the one who actually solved this issue.

Dynamics GP and ODBC DSNs

Jack Sowers of I.B.I.S. has a few quick tips around Dynamics GP and 64 Bit ODBC DSNs

Using ODBC to read the On-Line Field Descriptions File

Leslie Vail has an interesting look at using ODBC to read the On-Line Field Descriptions File. Anytime a post includes “If you still have your CDs from version 6” you know it’s not your average article.

Deploying GP via Group Policy

Jason Hartman of the Tech Roundup blog points us to the Microsoft White Paper on deploying GP via Group Policy.
The white paper is unclear on whether the ODBC connection has to be setup as well so if anyone has tried this, please let me know.
If you do need to deploy the ODBC separately, we have information on setting up the ODBC and replicating the connection.

Weekly Dynamic:Replicating the ODBC Connection

Lyle U from the Microsoft Dynamics GP Newsgroup had such a great tip last week that I have to include it as this week's Weekly Dynamic. He describes how to create two .reg files that you can then put on a shared drive or send to users to allow them to create their GP ODBC connection just by running the files. With this and Client Update, it's becoming MUCH easier to manage your Dynamics GP installs and updates. This is why you need visit the Newsgroup!
Here's how:
Rather than actually creating a DSN on every workstation. you can
easily create the DSN by importing registry entries. This method is
much quicker, and ensures the DSN is identical on all workstations.
1. Create the first DSN normally. (Video)
2. Go to Run and run "regedit" to open the registry editor.
3. Go to HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\odbc.ini and locate the DSN you created. Click on the DSN name to highlight it.
4. On the Registry Editor menu, click Registry > Export. Path the file
to a shared folder on the server (I usually create a folder under the
Install Template called "ODBC"), and name the file a name you will
recognize. Be sure to leave the extension as "reg." (ODBC1.REG)
5. Still at HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\odbc.ini\ and click on ODBC Data Sources.
6. On the Registry Editor menu, click Registry > Export. Path the file
to the same shared folder on the server used in step 4, and name the
file a name you will recognize. (I usually call it "ODBC.reg.") Be sure
to leave the extension as "reg." (ODBC2.REG)
7. On each subsequent workstation install, simply double click each of the .REG files, and answer Yes to allow it to write to the registry.