79
votes

I am trying to open a program for the first time on Windows XP Pro that uses PostgreSQL 9. I'm getting an error message that says :

A problem was encountered while trying to log into or create the production database. Details: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

In my ODBC manager, I have a list of User DSN's and System DSN's. I tried installing a postgres odbc driver to see if that would help, but it didn't.

There is a connect.dat file in the program file with a line saying "OLE DB Provider = MSDASQL". Changing this entry alters the error message I get to "Provider cannot be found, it may not be properly installed".

I don't know what provider name to insert to get this to work properly. I have done extensive research on this error to no avail. Any suggestions would be greatly appreciated.

9
If anyone still searching the solution to this problem, start R&D from ODBC Driver section. Check if the driver you specified is there or not.Ganesh Jadhav
This error tells me that there is no driver to run ODBC DSN. Install the given ODBC DRIVER MSI and see if error goes away.B. Shea
If using powershell to test, make sure to use "Windows Powershell ISE (x86)" instead of "Windows Powershell ISE".Ivan Chau

9 Answers

68
votes
  1. In reference to the error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.

    That error means that the Data Source Name (DSN) you are specifying in your connection configuration is not being found in the windows registry.

    • It is important that your ODBC driver's executable and linking format (ELF) is the same as your application. In other words, you need a 32-bit driver for a 32-bit application or a 64-bit driver for a 64-bit application.

      If these do not match, it is possible to configure a DSN for a 32-bit driver and when you attempt to use that DSN in a 64-bit application, the DSN won't be found because the registry holds DSN information in different places depending on ELF (32-bit versus 64-bit).

      Be sure you are using the correct ODBC Administrator tool. On 32-bit and 64-bit Windows, the default ODBC Administrator tool is in c:\Windows\System32\odbcad32.exe. However, on a 64-bit Windows machine, the default is the 64-bit version. If you need to use the 32-bit ODBC Administrator tool on a 64-bit Windows system, you will need to run the one found here: C:\Windows\SysWOW64\odbcad32.exe

      Where I see this tripping people up is when a user uses the default 64-bit ODBC Administrator to configure a DSN; thinking it is for a 32-bit DSN. Then when the 32-bit application attempts to connect using that DSN, "Data source not found..." occurs.

    • It's also important to make sure the spelling of the DSN matches that of the configured DSN in the ODBC Administrator. One letter wrong is all it takes for a DSN to be mismatched.

      Here is an article that may provide some additional details

      It may not be the same product brand that you have, however; it is a generic problem that is encountered when using ODBC data source names.

  2. In reference to the OLE DB Provider portion of your question, it appears to be a similar type of problem where the application is not able to locate the configuration for the specified provider.

56
votes

Got this error because I had the Data Source Name in User DSN instead of System DSN enter image description here

11
votes

The Problem might be from the driver name for example instead of DRIVER={MySQL ODBC 5.3 Driver} try DRIVER={MySQL ODBC 5.3 Unicode Driver} you can see the name of the driver from administration tool

4
votes

if you are using IIS, maybe you should try
"application pools" --> "DefaultAppPool" --> "application pools default value" --> "32-Bit-application-activ" --> set false

4
votes

In my case, it was working in x86 but not in x64.

It quite ridiculous, but in x64 the following change had to be added before it would work:

x86 -> szDsn = "DRIVER={MICROSOFT ACCESS DRIVER (*.mdb)};
x64 -> szDsn = "DRIVER={MICROSOFT ACCESS DRIVER (*.mdb, *.accdb)};

Note the addition of *.accdb.

3
votes

I got this with data driven tests using:

Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)

The problem is the above driver only is 32 bit. I had switched visual studio testsettings file to 64 bit to test a 64-bit-only application.

Switching back to 32 bit in the testsettings file fixed the issue.

using a test settings file

3
votes

Check the exact driver name in the ODBC Administrator tool. Press Windows key + R and then:

  • C:\Windows\System32\odbcad32.exe on 32-bit systems
  • C:\Windows\SysWOW64\odbcad32.exe on 64-bit systems

In my case it should have been Microsoft Access Driver (*.mdb, *.accdb) instead of Microsoft Access Driver (*.mdb).

0
votes

I tried the above but found my issue was I used a | in the name of the DSN (I have multipled ODBC connectors - one for each DB - to make sure I don't comingle data)

I replaced the | (pipe) with a _ and all now works fine.

I was trying to call SQL Server from Alteryx.

0
votes

Following the instructions here http://help.loftware.com/pages/viewpage.action?pageId=27099554 I had to install the Microsoft Access Database Engine 2010 Redistributable before I had the Excel driver installed to use the DSN-less connection I wanted to use from perl.