Microsoft Access SQL Database connection with Python 3.7.9 [duplicate] - sql

When trying to make a program on Windows that connects to a database via ODBC, I got the following error:
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
I'm sure my code is right. It even worked on a different PC.
Why am I getting this error? And How do I fix it?

What causes this error?
The error message tells you, simply put, that the ODBC Driver Manager could not find the driver you specified in your connection string or DSN.
This can have 3 common causes:
The driver you tried to use is not installed on your system
The driver is installed, however, it doesn't match bitness of the code you're running
You made an error in typing the driver name
How do I check which drivers are installed on my system?
You can check the drivers which are installed on your system by going to the ODBC Data Source Administrator. To open it, press ⊞ Win + R, and type in: odbcad32.exe. Then check the tab Drivers for installed drivers. The Name column indicates the exact name you should use in your connection string or DSN.
If you're on 64-bit Windows, that only lists the 64-bit drivers installed on
your system. To see which 32-bit drivers are installed, press press ⊞ Win + R, and type in: C:\Windows\SysWOW64\odbcad32.exe, and go to the Drivers tab again.
The driver is installed, but it might be the wrong bitness, what do I do?
Then, you have two choices, either adjust the bitness your program is running in, or install a driver with a different bitness.
Some of the drivers that are installed by default on Windows only have a 32-bits variant. These can't be used with 64-bits programs.
You can usually identify which bitness a program is running under in task manager. In Windows 10, all 32-bit programs have (32-bit) appended to their name. If that isn't there, you're likely running a 64-bit program, and most modern programming languages and environments run on 64-bit by default, but allow you to switch to 32-bit. However, the specifics for different programming languages are outside the scope of this question.
How can I verify I didn't mistype the driver name?
An ODBC connection string looks like this:
DRIVER={DriverName};ParameterName1=ParameterValue1;ParameterNameN=ParameterValueN;
The driver name part needs to be delimited by curly braces if it might contain special characters, and needs to exactly match the installed driver name, as found in the ODBC Data Source Administrator, including spaces and typographical characters, but excluding capitalization.
Note that for deployed code, the driver must be present on the computer/server running the code.
I don't have the driver, or have the wrong bitness, where do I get the right one?
That depends on which driver you want to use.
A list of common drivers with download locations (all 32-bit and 64-bit at the same URL):
The Microsoft ODBC Driver 17 for SQL Server
The Microsoft Access database driver, which is part of the Microsoft Access Database Engine. Note that simultaneous installations of 32-bit and 64-bit Access ODBC drivers are not supported.
The MySQL ODBC connector by Oracle
The open-source SQLite ODBC driver by Christian Werner (non-official)
psqlODBC, the official PostgreSQL driver
If the driver you want to use isn't listed, the location is usually easily found using Google.

In design mode, a value has been set to the property of
TFDConnection.ConnectionDefName must be empty.

Related

[RESOLVE]ODBC Driver Manager] Data Source name not found and no default driver specified

I created a vb project and made an installer of it, it works fine with my pc and it also works on some of the users who used the system on their machine, but then there's this particular user of received this error, please help T.T
I tried...
checking my connection string on my vb project just to make sure, but it's fine.
check if my system deployed is 32 bit and the MySQL ODBC connector, both are 32 bit.
tried checking if the MySQL ODBC driver is properly installed on the 32-bit ODBC data source,
I search this win + R (c:\windows\sysWOW64\odbcad32.exe) to make sure that I'm in a 32-bit data source since both 64 bit and 32-bit data source has the same name on my laptop.
also, i notice that the drivers installed on 32 bit data source doesn't have version,company and such (refer to image 2), while on the 64 bit data source it does have version, company and such (refer to image 1).
it turns out that the network of that particular user has block the access to the installed drivers, it got resolve when they connect to a different network.

Database query tool for Mac OS X?

I need to test one odbc driver for mac.
What are database query utilities using ODBC for Mac OS X like DBForge, OmniDB etc?
Presuming you are testing a driver bound to iODBC, the ODBC driver manager that Apple ships with macOS, you should install the latest iODBC SDK update, which comes with iODBC Test.command and iODBC Demo.app (found in /Applications/iODBC/). You can execute any arbitrary ODBC query through these tools.
ODBC Bench, a separate install which simulates TPC-A and TPC-C on your own equipment/network. (You'll need to build your own binary to test a 64-bit driver, as the downloadable pre-built binary is 32-bit only.)
Most GUI-space apps on macOS are shipped with binding to iODBC, and are thus also candidates for your use.

Relation between application .dll files and system installed .dll/.sys files (specifically, FTDI drivers)

I'm working on a project which uses the D2XX drivers from FTDI chip.
We are delivering the ftd2xx.dll file as part of our application. As far as I understand, the other files (e.g. ftdibus.sys) are installed on the system (at least for Windows) where the application runs. Linux is also a target for us, but let's ignore that for simplicity now.
My question is regarding the relation between these files? If, for example, I upgrade the ftd2xx.dll file delivered with our application, will users have to install the newest drivers? What if they do not?
In addition to the specific FTDI drivers, any general source of information on this area is also very welcome.
I used to work on a project that made use of FTDI's D2XX library.
There is no tight coupling between the exact version of ftd2xx.dll and ftdibus.sys. I believe the interface between ftd2xx.dll and the kernel mode driver is version independent at the basic feature level (at least since version 2.04.06 or so). There is even functions in the DLL to query DLL and driver versions respectively.
Thus, it can happen that they are 'out of sync'. I.e. ftd2xx.dll could be one from a more recent release than ftdibys.sys or vice versa. That is not a problem as such.
You are of course in complete control of the ftd2xx.dll version, but how does the driver package get installed? Is it installed as part of your application, or do you rely on the user obtaining the driver from another source? If your application has an installer, it could be an option to include FTDI's driver package in the installation. Thereby you will know which driver version is available.
What can be really tricky (and what has caused me headaches) is if there are other devices on the PC that use FTDI's chip. If such a device is supplied with media containing an older version of the driver and the user chooses to install this driver, it will simply overwrite any existing version of the driver (e.g. the version that your installer provided). This is a potential cause of regression, because FTDI has resolved a lot of bugs in the driver over the years.
If I were you, I would check the driver version at runtime and compare it to a version that is known to work (the version that you tested your application with). If the driver is older, suggest the user to upgrade it. Otherwise I would assume it is compatible.

Installing USB drivers before plugging in the device

We have a device that requires we install drivers before it's plugged in, otherwise we need to remove the drivers that Windows 8 and 10 automatically download.
How do we make a USB driver installer that can install correctly whether it's plugged in first or not?
On Windows 10, my simple driver for usbser.sys with just an INF file and a CAT file will automatically take precedence over Microsoft's usbser.inf that they supply in Windows 10. But if that doesn't happen for your particular driver/device, you might look into using DevCon, an open source utility from Microsoft that can be used to list devices and update their drivers. I have never used DevCon in an installer, but I think I have noticed other installers that use it. There is an MSYS2 package for DevCon.
We use DPinst which is a Driver Package installer program that Microsoft supply. It is quite flexible & straightforward to use & can give you a pretty standard wizard UI.

(Libre Office / Base Database) always tries to connect ODBC using iODBC, not unixODBC on Mac OSX 10.10

I am using Libre Office Version: 4.3.4.1 on my Mac OSX 10.10 Yosemite.
In Base Database, I would like to connect MS-SQL server using unixODBC DSN.
But it seems the Libre Office tries to connect via iODBC, not unixODBC.
(I never installed iODBC on my Mac.)
Here is what I tried.
Following instructions, I already setup unixODBC, FreeTDS using Homebrew and all the tsql/isql connection tests were fine.
After installing, I launched "Database Wizard" from Base database.
And choose 'ODBC' from "Connect to an existing database",
I entered s01, my unixODBC DSN name, to "Name of the ODBC data source on your system" field. (When I clicked 'Browse' no registered data source were shown.)
And I typed my unixODBC username and checked Password required.
When I clicked 'Test Connection' button and input the password, an error occurred as below.
[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded.
SQL Status: IM002
[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded
Does anyone have an idea to solve this problem?
I would recommend you stick with iODBC, the ODBC driver manager Apple has shipped as part of OS X since Jaguar (10.2). The version Apple bundles into Yosemite (10.10) remains a bit behind, at 3.52.6, so I would also recommend you update to 3.52.10.
iODBC and UnixODBC are built to be API equivalent, so you should just need to ensure that your drivers and DSNs are properly configured in the iODBC locations, optimally via iODBC Administrator.app (/Applications/iODBC/). System DSNs are recommended for most purposes.
/Library/ODBC/odbc.ini # System DSNs
/Library/ODBC/odbcinst.ini # System drivers
~/Library/ODBC/odbc.ini # User DSNs
~/Library/ODBC/odbcinst.ini # User drivers