Returning to the fundamentals: What exactly is a SQL Server Instance Name?

By Steve Endow

Many of my clients, especially non-technical users, are unsure about the SQL Server Instance Name for their Dynamics GP environment. It’s an understandable point of confusion since it’s not information they regularly need. However, even some IT professionals, who juggle various technical aspects, might not be well-versed in SQL Server specifics. Adding to the complexity is Dynamics GP’s use of ODBC DSNs, which further complicates the understanding of data access for those unfamiliar with it.

Let’s first address the commonly misunderstood ODBC DSN in Dynamics GP.

Upon launching Dynamics GP, the “Welcome to Dynamics GP” login window appears.

The first field, “Server,” is misleading as it doesn’t represent the actual server name but an ODBC Data Source Name (DSN). This DSN is simply a designated name for the SQL Server connection.

For standard GP setups, using the default value (currently Dynamics GP XXXX, where X denotes the version number) is recommended. Consistency in the ODBC DSN name across all GP workstations is crucial since it directly impacts how Dynamics GP encrypts and decrypts passwords.

Now, where is this ODBC DSN configured?

On the prevalent 64-bit Windows versions, the 32-bit ODBC Data Source Administrator tool is necessary to examine the ODBC DSN settings. This is another point of confusion, as Dynamics GP, being a 32-bit application, utilizes 32-bit ODBC drivers and consequently a 32-bit ODBC DSN.

In Administrative Tools on recent Windows versions, an option to launch “ODBC Data Sources (32-bit)” is available.

Older 64-bit Windows versions lack this separate 32-bit option, offering only the 64-bit version. To access the 32-bit Data Sources, you need to navigate through Windows Explorer to its location at:

C:\Windows\SysWOW64\odbcad32.exe

Launching either of these options will open the ODBC Administrator 32-bit window.

Note that the window explicitly indicates “32-bit” in its title. You can then select your Dynamics GP DSN and click “Configure.”

Finally, this will reveal your actual SQL Server instance name displayed in the “Server” field, which is linked to your Dynamics GP ODBC DSN.

This detailed method ensures you’re checking the correct SQL Server instance name on a machine with Dynamics GP installed. This is crucial because some clients might have multiple environments, SQL Servers, or SQL Server instances. It’s always best to verify, as a GP machine might be connected to a test SQL server instance.

If you have technical proficiency and access to the SQL Server or SQL Server Management Studio, a quicker way to verify the SQL instance name exists. When you log into Management Studio and access the GP SQL Server, the instance name is visible in Object Explorer.

In this scenario, my SQL Server utilizes a “default instance” named “GP2015,” matching the server name.

However, if your server has a “named instance,” the server name will be followed by a backslash and then the instance name.

Here, “GPDEV2” is the server name, but the named SQL Server Instance is “GPDEV2\GP2010.”

Caution is advised when retrieving the instance name from Management Studio. Multiple SQL Servers and instances might exist, so the one displayed upon logging in may not be the one Dynamics GP uses.

To be certain, locate a Dynamics GP machine definitively connected to your target SQL Server and check the ODBC DSN settings on that specific machine.

This explanation should clarify what a SQL Server Instance Name is and how to locate it within a Dynamics GP environment.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him onGoogle+andTwitter

http://www.precipioservices.com

Licensed under CC BY-NC-SA 4.0