I am unable to connect to mySQl db using pyodbc.
Here is a snippet of my script:
import pyodbc
import csv
cnxn = pyodbc.connect("DRIVER={MySQL ODBC 3.51 Driver}; SERVER=localhost;DATABASE=mydb; UID=root; PASSWORD=thatwouldbetelling;")
crsr = cnxn.cursor()
with open('C:\\skunkworks\\archive\\data\\myfile.csv','r') as myfile:
rows = csv.reader(myfile, delimiter=',', quotechar='"')
for row in rows:
insert_str = 'INSERT into raw_data VALUES(something, something)'
print insert_str
#crsr.execute(insert_str)
cnxn.commit()
myfile.close()
I get this error at the pyodbc.connect() line:
pyodbc.Error: ('IM002', '[IM002]
[Microsoft][ODBC Driver Manager] Data
source name not found and no default
driver specified (0)
(SQLDriverConnectW)')
I have another question regarding this error (and Python scripts in general). When I run this as a script, it fails silently (I was expecting a stack trace). I have to type each line in manually to find where the error occured.
I am being a bit lazy for now (no exception handling) - is this normal behaviour of a Python script without exception handling to fail silently?
[Edit]
I am not using mysqldb because I am already using pyodbc to extract my data from another source (MS Access). Ok, not a good reason - but I am already grappling with pyodbc and I dont really fancy having to wrestle with another library/module/package(whatever its called in Python) for a "one off" job. I just want to move my data of from various data sources in the Windows environment to mySQl on Linux. once on Linux, I'll be back on terra firma.
That is the entire 'script' right there. I just saved the code above into a file with a .py extension, and I run python myscript.py at the command line. I am running this on my XP machine
I had this same mistake so I went over all the version I was using for the connection. This is what I found out:
For Python 2.7 32 bits:
- pyodbc must be 32bits
- the DB Driver must be 32bits. (Microsoft Access should be 32 bits too)
For those who use the 64 bits version. You should check that everything is 64 bits too.
In my case I was trying to connecto to an Oracle DB and Microsoft Access DB so I had to make the following components match the architechture version:
pyodbc (MS Access)
python
cx_Oracle (Oracle dialect for SQLalchemy)
Oracle instantclient basic (Oracle. Do not forget to create the environment variable)
py2exe (Making the excecutable app)
Is that your driver name right?
You can check your driver name in
Windows -> Control panel -> System and security -> Administrative tools -> ODBC Data Sources -> Driver tab
then copy the river name to the first parameter
like
cnxn = pyodbc.connect("DRIVER={MySQL ODBC 5.3 ANSI Driver}; SERVER=localhost;DATABASE=books; UID=root; PASSWORD=password;")
And my problem solved
or you may not install the driver and the step is simple.
MySQLdb (or oursql) and pyodbc both have the same interface (DB-API 2), only you don't have to deal with ODBC's issues if you use the former. I strongly recommend you consider using MySQLdb (or oursql) instead.
First, According to the official docs, if you want to connect without creating a DSN, you need to specify OPTION=3 in the connection string:
ConnectionString = "DRIVER={MySQL ODBC 3.51 Driver};SERVER=localhost;DATABASE=test;USER=venu;PASSWORD=venu;OPTION=3;"
If that fails to work, I'd further troubleshoot by creating a DSN.
Second, no Python should not be failing silently. If that is the case when you run your script, there is something else amiss.
only need install mysql-connector-odbc-3.51.28-win32.msi.
and pyodbc-2.1.7.win32-py2.7.exe.
of course, you have ready installed MySQL and python 2.7.
example:
import pyodbc
cndBase = pyodbc.connect("DRIVER={MySQL ODBC 3.51 Driver}; SERVER=localhost; PORT=3306;DATABASE=nameDBase; UID=root; PASSWORD=12345;")
ptdBase = cndBase.cursor()
query_str = 'SELECT* FROM nameTabla;'
rows = ptdBase.execute(query_str)
for rw in rows:
print list(rw)`enter code here`
I was getting the same error. It seemed the driver i was using to make the connection was not the driver installed in my system.
Type ODBC on windows run and select ODBC Data Source(32/64) based on where you have installed the driver.
From there click on System DSN and click add. From there you can see the MySQL driver installed in your system. Use the ANSI driver in your code where you are making the connection.
Related
We have a Python 3.7 application running on an AWS EC2 instance (Amazon Linux) that performs SQL queries against a Cloudera Impala service using pyodbc (4.0.27) and the Cloudera Impala ODBC driver (installed using ClouderaImpalaODBC-2.6.5.rpm). This application has been running successfully for several years.
I'm currently trying to get the application running in a Docker container running Ubuntu 18.04.4 LTS, but having trouble with the following error when running even the most basic query (e.g. SELECT 'HELLO'):
Error: ('HY000', '[HY000] [Cloudera][ImpalaODBC] (110) Error while executing a query in Impala: [HY000] : ParseException: Syntax error in line 1:\\n\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\\n^\\nEncountered: Unexpected character\\nExpected: ALTER, COMMENT, COMPUTE, COPY, CREATE, DELETE, DESCRIBE, DROP, EXPLAIN, GRANT, INSERT, INVALIDATE, LOAD, REFRESH, REVOKE, SELECT, SET, SHOW, TRUNCATE, UPDATE, UPSERT, USE, VALUES, WITH\\n\\nCAUSED BY: Exception: Syntax error\\n\\x00\u6572\u3a64\u5520\u656e\u7078\u6365\u6574\\u2064\u6863\u7261\u6361\u6574\u0a72 (110) (SQLExecDirectW)')"}
Needless to say this looks like a string encoding problem.
Some context housekeeping:
the python code on both systems (Amazon Linux / Ubuntu) is identical
the Impala ODBC driver installations on both systems have the same version (2.6.5); the Impala ODBC driver for Ubuntu was downloaded directly from the Cloudera website (https://www.cloudera.com/downloads/connectors/impala/odbc/2-6-5.html)
the Impala ODBC connection params are identical except for the OS specific items:
"HOST": "[host]"
"PORT": 21050
"Database": "[database]
"UID": "[username]"
"PWD": "[password]"
"Driver": "{/opt/cloudera/impalaodbc/lib/64/libclouderaimpalaodbc64.so}"
"UseSASL": 1
"AuthMech": 3
"SSL": 1
"CAIssuedCertNamesMismatch": 1
"TrustedCerts": "[path_to_certs_file]"
"TSaslTransportBufSize": 1000
"RowsFetchedPerBlock": 10000
"SocketTimeout": 0
"StringColumnLength": 32767
"UseNativeQuery": 0
The application appears to be connecting successfully to Impala as there is no error calling pyodbc.connect(**config, autocommit=True) or getting the cursor from the connection (have tried with invalid creds to make sure, and get the usual connection errors when creds are wrong). The details of the error message indicate the correct ODBC driver is being used
I have tried playing around with different values for the Impala ODBC driver param "DriverManagerEncoding" such as "UTF-16", "UTF-32" or not having it at all (which is the case for the Amazon Linux setup) but always get the same error.
I also tried using the odbclinux tool isql on both system to try troubleshooting that way; was able to connect successfully from Amazon Linux system, but could never connect on Ubuntu - consistently get the following (not sure if this is related or some other issue):
iusql -v [DSN]
[unixODBC][
[ISQL]ERROR: Could not SQLDriverConnect
Found the culprit - is was the setting DriverManagerEncoding in /opt/cloudera/impalaodbc/lib/64/cloudera.impalaodbc.ini:
[Driver]
## - Note that this default DriverManagerEncoding of UTF-32 is for iODBC.
## - unixODBC uses UTF-16 by default.
## - If unixODBC was compiled with -DSQL_WCHART_CONVERT, then UTF-32 is the correct value.
## Execute 'odbc_config --cflags' to determine if you need UTF-32 or UTF-16 on unixODBC
## - SimbaDM can be used with UTF-8 or UTF-16.
## The DriverUnicodeEncoding setting will cause SimbaDM to run in UTF-8 when set to 2 or UTF-16 when set to 1.
DriverManagerEncoding=UTF-32
ErrorMessagesPath=/opt/cloudera/impalaodbc/ErrorMessages/
LogLevel=0
LogPath=
SwapFilePath=/tmp
## - Uncomment the ODBCInstLib corresponding to the Driver Manager being used.
## - Note that the path to your ODBC Driver Manager must be specified in LD_LIBRARY_PATH (LIBPATH for AIX).
## - Note that AIX has a different format for specifying its shared libraries.
# Generic ODBCInstLib
# iODBC
# ODBCInstLib=libiodbcinst.so
# SimbaDM / unixODBC
#ODBCInstLib=libodbcinst.so
# AIX specific ODBCInstLib
# iODBC
#ODBCInstLib=libiodbcinst.a(libiodbcinst.so.2)
# SimbaDM
#ODBCInstLib=libodbcinst.a(odbcinst.so)
# unixODBC
ODBCInstLib=libodbcinst.a(libodbcinst.so.1)
This file was autogenerated as part of the installation of the driver. Note the comments about iODBC vs unixODBC - we have installed only the later.
Once I commented that configuration out, our python app worked. It also fixed the problem with iusql (which is part of the unixODBC install).
Bonus content:
I had also come across a problem with iqsl (not iusql) - was getting this error/output for the command isql -v [DSN]:
[S1000][unixODBC][Cloudera][ODBC] (11560) Unable to locate SQLGetPrivateProfileString function.
[ISQL]ERROR: Could not SQLConnect
The error is related to the config param ODBCInstLib in the same ini file. Once I changed it from the default libodbcinst.a(libodbcinst.so.1) to /usr/lib/x86_64-linux-gnu/libodbcinst.so it worked. Found the answer was in this post, which actually helped solving my original problems:
Can't connect to snowflake via unixODBC. Error: [S1000][unixODBC][Snowflake][ODBC] (11560) Unable to locate SQLGetPrivateProfileString function
This is an overused topic of discussion but the waters are still unclear. I have developed a program that uses pyodbc to connect to a .mdb file, it successfully works when I use the 32-bit version of Python and only if on the consrtuctor string write the following constr = "DRIVER={{Microsoft Access Driver (*.mdb)}};Dbq={};".format(dbname) so I naturally thought it was a mismatch between 32bit access and 64bit Python.
However when I tried to make a simple test:
import pyodbc
conn=pyodbc.connect(r'Driver={Microsoft Access Driver (*.mdb, *accdb)};DBQ=C:\Users\emate\OneDrive\Desktop\pyodbctest\Database2.accdb;')
cursor=conn.cursor()
cursor.execute('SELECT * FROM Table1')
for row in cursor.fetchall():
print(row)
I ran it and got the same error. The problem is I checked the Office Version and says it is 64bit,python is also 64bit so if it is not a mismatch problem then what is this problem?
I want to run the program on a raspberrypi microcomputer (64bit) and it is tremendously hard to use a 32bit version on it to just run the program.
I'm trying to connect to a database on an IBM machine, and I can connect just fine via the IBM desktop client "IBM Data Studio." However, when I try to connect with pyodbc it fails to connect. I've received a series of errors but it seems the main response is along the lines of the following
pyodbc.OperationalError: ('08001', u'[08001] [Microsoft][ODBC SQL Server Driver]
[TCP/IP Sockets]SQL Server does not exist or access denied. (17)
(SQLDriverConnect); [08001] [Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen (
Connect()). (10061); [08001] [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute (0)')
My code follows:
import pyodbc
# Specifying the ODBC driver, server name, database, etc. directly
cnxn = pyodbc.connect('DRIVER={SQL Server};SERVER=*****; PORT=50000;DATABASE=****;UID=***;PWD=***')
# Create a cursor from the connection
cursor = cnxn.cursor()
cnxn.close()
I am working on a Windows machine.
You cannot use an ODBC Driver for Microsoft SQL Server, to connect to an instance of IBM DB2 (nor to any DBMS other than Microsoft SQL Server).
You need an ODBC Driver for IBM DB2 for this connection, such as those from my employer.
You could also use an ODBC-to-JDBC Bridge Driver, in combination with a JDBC Driver for IBM DB2, such as JTOpen (open source, from IBM).
Just because a jdbc connection from Data-Studio is working, it does not mean that your pyodbc will connect to Db2. pyodbc does not use jdbc, instead it will use the CLI/ODBC interface to Db2 which gets implemented by a suitable driver.
To use Db2 from pyodbc on Windows, ensure you first have either a Db2-client installed on Windows, or a Db2-server installed installed on Windows.
There are many kinds of Db2-clients. Much depends on the operating-system that runs your Db2-server (Z/OS, i-Series, Linux, Unix, Windows), and what kind of activities you want to perform on the client (developing, administering/monitoring, querying, or all three).
For some target platforms there are non-IBM drivers, but I won't discuss those.
In python, you can choose to connect to a database either with a DSN (Data Source Name) (usually this involves a shorter connection string)
or without a DSN (longer connection string containing all the details).
When learning, it may be easier to get Microsoft Windows to do most of the initial work with odbcad32.
This is most easy if the Db2-client is already configured to access one or more Db2-databases . The prereq is that the driver supports CLI/ODBC.
To define a DSN (either a system-DSN or a user-DSN) use the Microsoft odbcad32 tool to point to your Db2 database and verify connectivity.
If the Db2-server runs on Z/OS or i-Series, special licensing requirements may apply depending on whether you are directly connecting to the target Db2-server or whether you are using a Db2-connect gateway.
Take a note of the exact DRIVER string inside odbcad32 for the Db2-database, including case and spaces because you will need that in your python code.
For example, that driver name might look like 'IBM DB2ODBC DRIVER - DB2COPY1' if you have a local Db2-server installed on Windows (such as the free Db2-Express-C).
Verify that the connection to the Db2-database is successful inside odbcad32. That is crucial.
When odbcad32 succeeds to connect then pyodbc will succeed to connect usually.
In your python code, your connection-string can either use the DSN or explicitly quote the DRIVER/SERVER/PORT/DATABASE/UID/PWD, along with any other required settings on the connection string.
Remember also that you don't have to use pyodbc. There are other options for python to interact with Db2-Servers. Make an informed choice and do your research.
You can also use the IBM supplied module "ibm_db" or the DBI interface module "ibm_db_api", or if you are using an object relational mapper you can use the SQLAlchemy adapter (ibm_db_sa), or you can use django framework.
Read all about that in the Db2 documentation here.
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.swg.im.dbclient.python.doc/doc/c0054366.html
I have solved the problem! The issue was that I was missing the "iSeries Access ODBC Driver". I don't think it's available online, although I could be wrong, I had to have our database guy help install it. Now I can connect through both the ibm_db and pyodbc libraries, after setting up my DSN under "odbcad32.exe." This took a while to solve but mostly because of the lack of informative documentation from IBM. Hopefully, this helps anyone in the same situation.
I'm setting up a python script to connect to an instance of the azure cloud database, and seeing a difference in the connection when I use IDLE vs when I try to execute the connection from a script. For example, when I do the following in IDLE:
>>> import pyodbc
>>> conn = pyodbc.connect('DRIVER={SQL Server};SERVER=<my.database.host.info>,1433', user='<my_username#mydatabase', password='password', database='database')
I'm able connect successfully and execute a basic query against one of the tables in the database.
However when I use the same connection string (copied from the IDLE console) in a script, I get the following error:
pyodbc.Error: ('IM002', '[IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0) (SQLDriverConnect)')
Usually, the issue is raised because the 32/64 bit version of python environment and odbc driver are mismatched.
You may check the python version and odbc driver version you used to run the script. You have to manage to change both of them need to be 32-bit (or both 64-bit) in order for this to work.
You can get the specified version of pyodbc extension from http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyodbc.
I am on Win7 x64, using Python 2.7.1 x64. I am porting an application I created in VC++ to Python for educational purpouses.
The original application has no problem connecting to the MS Access 2007 format DB file by using the following connection string:
OleDbConnection^ conn = gcnew OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0; Data Source=|DataDirectory|DB.accdb");
Now, when I try to connect to the same DB file (put in C:\ this time) in Python using pyodbc and the following conenction string:
conn = pyodbc.connect("DRIVER={Microsoft Access Driver (*.mdb, *.accdb)}; Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\DB.accdb;")
, and no matter whether I keep the OLEDB provider or I use the Provider=MSDASQL; as mentioned here (MS mentions it's not availiable for 64bit), I keep getting the following error:
pyodbc.Error: ('IM002', '[IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0) (SQLDriverConnectW)')
What might cause this problem?
ADD:
I have looked into pyodbc docs more closely and tried conn = pyodbc.connect("Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=c:\\DB.accdb;") - the same error. This is really weird, since the pyodbc.dataSources() shows that I have this provider.
ADD2:
I tried win32com.client usage such as here in order to connect by using OLE DB - no success. Seems that it's impossible, nothing works.
Try to use something like the following instead of using the same string as the one for OLeDb:
"Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=C:\DB.accdb;"
You may not be able to talk to the driver directly from your x64 Python application: Access 2007 and its ACE driver are 32 bits only.
Instead, get the ACE x64 driver for Access 2010, but be careful that if you already have Access or the ACE driver 32bit installed, it won't work.
I would stick to the 32bit versions of Python and of the ACE driver if you expect your app to be run on other systems: it is not recommended to mix x64 and x86 versions of Office tools and drivers, you'll probably end up with lots of issues if you do.
If the issue is not with the 32/64bit mix, then maybe this question has the answer you seek.