In my Access database, I reference the DSN, "mydatasourcename" to connect to an online MySQL database. It is a machine DSN. Somehow through the course of editing my config files, a phantom DSN was created. This DSN is now out of date and I need to update it with the new hostname (after having migrated the MySQL Server). But the config file is nowhere to be found. It does not show up in either 32-bit or 64-bit "ODBC Data Sources" forms. I have searched "mydatasourcename" in the Registry Editor and it is not there either. Mysteriously, when I open an Access linked table referencing "mydatasourcename" it opens a MySQL ODBC Connector dialogue with the old connection information in it. How is it doing this? Where is it getting the connection string information? To answer this question, I am requesting a list of the places the ODBC driver looks for configuration files and how to access them so I can delete the old configuration file. I am using MySQL ODBC Connector 8.0.16. Thank you.
EDIT: The connection string found in my linked table is definitely looking outside of Access for connection info based on the fact that is referencing a DSN. The connection string in one of my linked tables is the following: "ODBC;DSN=mydatasourcename;;TABLE=qrychemigationapplications_materialsrequired1"
On Windows, ODBC DSN information is stored in the Windows Registry. System DSNs can be found in the registry keys
DSNs for 64-bit drivers: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
DSNs for 32-bit drivers: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
and User DSNs can be found in
HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI
If a DSN does not appear in the ODBC Administrator (odbcad32.exe) it might be because the DSN name is not included in the list of DSNs in the corresponding subkey
...\ODBC.INI\ODBC Data Sources
Paths to odbcad32.exe:
x86:
%windir%\syswow64\odbcad32.exe
x64:
%windir%\system32\odbcad32.exe
I was able to find the "Machine Data Sources" that Microsoft Access creates in the Windows Registry Here:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\ODBC\ODBC.INI\ODBC
Data Sources
The "Machine Data Sources" that are in this part of the registry, seem to be accessible only via MS Access. If you look for them instead using the standard Windows ODBC Data Source Administrator "widgets" (32 or 64 bit), you just don't see the "Access Created" Machine Data Sources for some reason. If anyone can tell us why, that would be great!
What's more frustrating, is that at least with the latest Microsoft Access Office 365 version, you can only create NEW Machine Data Sources. You can't delete or edit existing "Machine Data Sources".
That being said, if you avoid creating the "Machine Data Sources" using Microsoft Access itself, and instead use the standard 64 Bit Windows ODBC Data Source Administrator "widget", then for whatever reason Access will see those that you create in this way.
So having the issue that you're describing, just seems to be the result of some weird design that Microsoft has implemented specifically in regard to Microsoft Access ODBC connections, for a reason that escapes me.
Hope this helps!
Below is an alternative to accessing the Windows Registry:
Control Panel
Administrative Tools
ODBC Data Sources (32-bit or 64-bit)
Click the tab for: User DSN, System DSN, or File DSN
Click the name of the Data Source
Click Configure... if you would like to view or modify the details of the data source
Related
Since I don't like reading long questions myself I'll make it quick and dirty:
Starting Point:
MySQL DB on Server
Win10 machine with Excel (Office 365)
ODBC Driver installed
Test with ODBC connector works fine:
Goal:
Connecting from Excel to the DB via ODBC
Problem:
When choosing the DSN, the following error appears:
!BUT! I can connect from other workstations just fine (same setup/credentials).
Checklist:
IP from this (and other workstations) are allowed on the server (and are correct)
Excel and drivers are all 32 bit (checked on excel 64 with correct driver, same problem)
Since the connection test is successful, the login credentials are obviously correct
Steps taken in excel:
open Excel
choose ODBC:
choose saved (and tested) connection and press "ok":
No further steps are taken within excel.
What else could I check? What am I missing here?
The error message shows that MySQL is receiving esa as the username. Double-check that your DSN does not have the wrong username value saved.
I'm guessing that your Windows, Excel, and intended ODBC driver are all 64-bit.
You might have a 32-bit User DSN that's getting in the way of a 64-bit User DSN; best to only use System DSNs on 64-bit Windows, as discussed here. Be sure to use both 32-bit and 64-bit ODBC Administrators (C:\Windows\SysWoW64\odbcad32.exe and C:\Windows\System32\odbcad32.exe, respectively) to check.
I have an old (created circa 1997 I believe) Microsoft Access database that has a linked table, to which only Windows XP users can connect.
When I do the following in the Immediate window
?CurrentDb.TableDefs("my linked table name").Connect
I see the following connection string:
ODBC;DSN=(some data source name);UID=(uid);PWD=(pwd);APP=2007
Microsoft Office
system;DATABASE=(someDbName);Network=(someNetworkName);
I can't figure out based on this connection string where it's trying to connect to. For example, I would expect a machine name instead of a Network name. I tried loading up the ODBC data source administrator on the machine where the connection does work, but I can't see any data source name matching the one above. I'm also not sure what the 'APP' attribute means... is that supposed to be the app from which we're connecting, or the app to which we're connecting?
I suspect that I just need to install a driver, but I have no idea which one to install.
Can anyone suggest a way I can figure out where this linked table is linked to?
I had to find the DSN referenced by the connection string, because it had the server name to connect to (as well as a pointer to a driver). I ended up exporting the DSNs from the registry of a working 32-bit machine, and editing them to go to WOW6432Node of HKLM/Software and imported them to 64-bit machines and installed appropriate driver (specified in DSN) and everything worked.
The ultimate goal is for users to be able to run a report that looks pretty and grabs current information from our database. We'd like to use SQL Report Builder since we're already using it for other reports. The database is Cisco UCCX and we're accessing it with an ODBC connection from our reporting services SQL Server 2008 R2.
We've successfully setup System ODBC connections with both 64bit and 32bit drivers. When trying to access the connections though, we're receiving errors.
Using the 32bit driver, we try to create a Data Source in SSRS for use by Report Builder and receive the error:
"ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application"
Using the 64bit driver, we can successfully create and test the ODBC connection as a Data Source, but then when we attempt to create a Dataset with it in Report Builder, we get this error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Error received using the 64bit driver for ODBC connection
I ran into this recently. You need to have the same name for both 32 and 64bit DSNs. It's annoying because SSRS can run 64bit, but reportbuilder only exists in 32bit. So parts of reportbuilder seem to work (like running queries), but some don't (like refreshing query fields). Just have a DSN for both 32bit and 64bit, then make sure they're both the same name and the problems should stop.
You may be hitting an old but recurring issue with minor corruption in the Windows Registry.
The corruption takes the form of entries containing this 4-character string —
#=""
These entries aren't visible anywhere except Registry export files — the Registry Editor ignores them completely — but they can lead to a number of undesired behaviors, including the error you report.
NOTE: On your 64-bit Windows machine, there are naturally some complications tied to the 32-bit Registry. This Microsoft KB article may be sufficient to get you through these.
I suggest that you use the 64-bit Registry Editor (%systemroot%\system32\regedit) to export the following branches (where these problematic entries tend to be found) —
HKEY_LOCAL_MACHINE\Software\ODBC
HKEY_CURRENT_USER\Software\ODBC
HKEY_LOCAL_MACHINE\Software\WOW6432Node\ODBC
HKEY_CURRENT_USER\Software\WOW6432Node\ODBC
Edit these files in any text editor (Notepad or Wordpad are generally fine), and delete all lines which consist of that 4-character string, above. Then, delete the Registry tree segment(s) you exported, and import from the edited files — thereby restoring the tree segment(s), minus the corruption.
It won't hurt to repeat the above process with the 32-bit Registry Editor (%systemroot%\syswow64\regedit), but as you've described the issue, I don't think you'll find any #="" in the 32-bit export.
Im having trouble using the MySQL ODBC connector.
I have a MS access frontend that im trying to connect to a MySQL DB. It connects fine when running the frontend and DB on my dev machine.
I have moved the front end and DB onto the clients server. The clients assess the fornt end via a shared folder on the individual user PCs. I have set up a file DSN ODBC connection as below. When i open the front end on one of the clients PCs i get the ODBC--call failed.
How do i get the linked tables to look at the server MySQL DB considering ms access is not installed on the server. I have tried to set uo the file DSN via the users pc i.e. open linked table manager and open the File DSN get the ODBC--call failed on connect.
File DSN set up
[ODBC]
DRIVER=MySQL ODBC 5.3 Unicode Driver
UID=root
PASSWORD=root
DFLT_BIGINT_BIND_STR=1
PORT=3306
DATABASE=productionlist_be
SERVER=localhost
thanks in advance Kelly
Welcome to stack-overflow Kelly.
You are missing few points.
The MySQL database Server must be accessible by all your clients.
Either a local machine hosting MySQL server or from internet its up
to you
Must have a static IP or domain name.
Access Front-Ends should not be shared but sent to all of your clients/employees
(This way you are achieving true "multi user access" and thats the main idea behind front and back ends)
All of your client PC must have MySQL ODBC driver installed
All of your clients must have required version of Access or Access Runtime installed
Only after setting up all this, you can think about distributing your application to your clients.
Modify your File DSN replace the localhost with the MySQL Database server ip
like
SERVER=SERVER_NAME_OR_IP
Also it is best to refresh the odbc links via VBA code
you will find much help here:
How do you programmatically update a linked table in Access that will refresh data types too?
OR
Relinking database tables: Access, VBA
hope this helps to get started :)
I have an asp application residing on Windows server 2003 -32bit and backend for the application is MS Access 2000. When I upgrade it to MS Access 2010, it throws error: 'Unrecognized Database format'
I even tried to upgrade Access driver on server but of no luck.
What am I missing?
Make sure you have the ACE drivers installed. You said you updated the Access driver on the server but I'm not sure you actually installed the drivers that are needed for the new .accdb format.
By default, Windows only contains drivers for Jet, that allow you to use .mdb Access databases without installing anything new.
On the other hand, the new 2007/2010 Access format '.accdb needs to have the drivers installed separately.
You also need to make sure that your connection string to the database is updated:
string constr = #"Provider=Microsoft.ACE.OLEDB.12.0;Mode=16;Data Source=C:\...\mydb.accdb;user id=;password=;";
In addition to upgrading the database file itself from .mdb to .accdb you'll need to make two changes on the server:
You'll need to download and install the Access Database Engine, available here.
You'll also need to update your connection details for your ASP application. For a DSN-less connection you'll have to update your connection string to one of the formats described here. For example, an OLEDB connection string will have to be updated to Provider=Microsoft.ACE.OLEDB.12.0;.