Python ODBC bridge

Overview

pyodbc

Build Status Windows Status PyPI

pyodbc is an open source Python module that makes accessing ODBC databases simple. It implements the DB API 2.0 specification but is packed with even more Pythonic convenience.

The easiest way to install is to use pip:

pip install pyodbc

Precompiled binary wheels are provided for most Python versions on Windows and macOS. On other operating systems this will build from source. Note, pyodbc contains C++ extensions so you will need a suitable C++ compiler on your computer to install pyodbc, for all operating systems. See the docs for details.

Documentation

Release Notes

Comments
  • Cursor throws an error when trying to insert in SQL Server database when fast_executemany flag is set

    Cursor throws an error when trying to insert in SQL Server database when fast_executemany flag is set

    Please first make sure you have looked at:

    • Documentation: https://github.com/mkleehammer/pyodbc/wiki
    • Other issues

    Environment

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: 2.7.14
    • pyodbc: 4.0.23
    • OS: MacOS
    • DB: SQL Server
    • driver: ODBC Driver 13 for SQL Server

    Issue

    Trying to use fast execute many option to insert data to the database throws the error shown below. It works if the flag is not set.

    Expected behavior:

    Cursor should be able to write to database without throwing an error.

    Observed behavior:

    ---------------------------------------------------------------------------
    Error                                     Traceback (most recent call last)
    <ipython-input-24-5e5f851229b4> in <module>()
          1 cursor.fast_executemany = True
    ----> 2 cursor.executemany(query, x.values.tolist())
    
    Error: ('HY010', u'[HY010] [unixODBC][Driver Manager]Function sequence error (0) (SQLParamData)')
    
    opened by manrajgrover 64
  • pip install pyodbc failing: error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

    pip install pyodbc failing: error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

    Please first make sure you have looked at:

    • Documentation: https://github.com/mkleehammer/pyodbc/wiki
    • Other issues

    Environment

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: 2.7.6
    • pyodbc: Latest version
    • OS: ubuntu 14.04.5
    • DB:
    • driver:

    Issue

    pip install pyodbc --user Collecting pyodbc Using cached pyodbc-4.0.17.tar.gz Building wheels for collected packages: pyodbc Running setup.py bdist_wheel for pyodbc ... error Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-YtLrrj/pyodbc/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" bdist_wheel -d /tmp/tmp5eqhA5pip-wheel- --python-tag cp27: running bdist_wheel running build running build_ext building 'pyodbc' extension creating build creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/src x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPYODBC_VERSION=4.0.17 -DSQL_WCHART_CONVERT=1 -I/usr/include/python2.7 -c src/textenc.cpp -o build/temp.linux-x86_64-2.7/src/textenc.o -Wno-write-strings cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] In file included from src/textenc.cpp:2:0: src/pyodbc.h:56:17: fatal error: sql.h: No such file or directory #include <sql.h> ^ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1


    Failed building wheel for pyodbc Running setup.py clean for pyodbc Failed to build pyodbc Installing collected packages: pyodbc Running setup.py install for pyodbc ... error Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-YtLrrj/pyodbc/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-CRLrEJ-record/install-record.txt --single-version-externally-managed --compile --user --prefix=: running install running build running build_ext building 'pyodbc' extension creating build creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/src x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPYODBC_VERSION=4.0.17 -DSQL_WCHART_CONVERT=1 -I/usr/include/python2.7 -c src/textenc.cpp -o build/temp.linux-x86_64-2.7/src/textenc.o -Wno-write-strings cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] In file included from src/textenc.cpp:2:0: src/pyodbc.h:56:17: fatal error: sql.h: No such file or directory #include <sql.h> ^ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

    ----------------------------------------
    

    Command "/usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-YtLrrj/pyodbc/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-CRLrEJ-record/install-record.txt --single-version-externally-managed --compile --user --prefix=" failed with error code 1 in /tmp/pip-build-YtLrrj/pyodbc/

    opened by wondernath 38
  • Cannot insert strings with a length greater than 2000 into columns with a datatype of varchar(max) or nvarchar(max) using parametrised queries

    Cannot insert strings with a length greater than 2000 into columns with a datatype of varchar(max) or nvarchar(max) using parametrised queries

    Environment

    • Python: 3.8.5
    • pyodbc: 4.0.30
    • OS: macOS 10.5.7
    • DB: MS SQL Server 2017 and 2019
    • driver: microsoft/mssql-release/msodbcsql17: stable 17.6.1.1

    Issue

    I cannot insert strings with a length greater than 2000 into columns with a datatype of varchar(max) ornvarchar(max) using parametrised queries.

    In particular the POC (see below) fails with following output:

    started
    non-param: len(content)=2001: success
    Traceback (most recent call last):
      File "test.py", line 54, in <module>
        cursor.execute(sql, (content,))
    pyodbc.ProgrammingError: ('42000', "[42000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Cannot convert to text/ntext or collate to 'Latin1_General_100_CI_AS_SC' because these legacy LOB types do not support UTF-8 or UTF-16 encodings. Use types varchar(max), nvarchar(max) or a collation which does not have the _SC or _UTF8 flags. (4189) (SQLParamData)")
    

    Every parametrised insert with a string having a length greater than 2000 fails with the above error message relating to a text/ntext conversion or Latin1_General_100_CI_AS_SC collation, which is strange considering that only plain ASCII is inserted.

    How can I resolve this issue and insert strings of any length into the database?

    POC:

    import pyodbc
    
    host = 'tcp:127.0.0.1,1433'
    db = 'pyodbc_test'
    user = 'sa'
    pwd = '[email protected]'
    
    print('started')
    
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+host+';DATABASE='+'master'+';UID='+user+';PWD='+ pwd, autocommit=True)
    cursor = cnxn.cursor()
    
    try:
        cursor.execute(f'CREATE DATABASE {db} COLLATE Latin1_General_100_CI_AS_SC')
    except pyodbc.ProgrammingError as e:
        pass # database exists
    
    cursor.execute(f'USE {db}')
    
    try:
        cursor.execute("""
            CREATE TABLE msg (
                id int identity(1,1) not null,
                content varchar(max) not null
            );""")
    except pyodbc.ProgrammingError as exc:
        pass # table exists
    
    content = 2001 * 'A'
    
    cursor.execute(f"""
        INSERT INTO msg (content)
        VALUES ('{content}')""")
    print(f'non-param: {len(content)=}: success')
    
    # fails (pyodbc 4.0.30)
    sql = f"""
          INSERT INTO msg (content)
          VALUES (?)"""
    cursor.execute(sql, (content,))
    print(f'param: {len(content)=}: success')
    
    print('finished')
    
    Investigating Environment or Driver Issue 
    opened by nlykkei 36
  • PYODBC - Won't create connection in Anaconda3 (Python 3.6)

    PYODBC - Won't create connection in Anaconda3 (Python 3.6)

    Please first make sure you have looked at:

    • Documentation: https://github.com/mkleehammer/pyodbc/wiki
    • Other issues

    Environment

    Windows WSL Bash

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: Anaconda (python 3.6)
    • pyodbc: 3.0.10
    • OS: Ubuntu 16.04 and WSL Bash
    • DB: SQL Server
    • driver: ODBC Driver 13 for SQL Server

    Issue

    Although I was able to install the pyodbc package in Anaconda3, and the "import pyodbc" module load without any errors. But, the connection string line error-out giving the following error:

    [email protected]:~$ python Python 3.6.0 |Anaconda 4.3.1 (64-bit)| (default, Dec 23 2016, 12:22:00) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux Type "help", "copyright", "credits" or "license" for more information. import pyodbc cnxn = pyodbc.connect('DRIVER={ODBC Driver 13 for SQL Server};SERVER=MTRINIDADLT2,51417;DATABASE=master;UID=sa;PWD=$SqlPwd01!') Traceback (most recent call last): File "", line 1, in pyodbc.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib '/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.7.0' : file not found (0) (SQLDriverConnect)")

    error_pyodbc_01_2017-05-02_8-50-56 error_pyodbc_02_2017-05-02_8-50-56

    Often it is easiest to describe your issue as "expected behavior" and "observed behavior".

    opened by MaximoTrinidad 35
  • Timeout keyword ignored in pyodbc.connect()

    Timeout keyword ignored in pyodbc.connect()

    Hi all, This is linked to an old closed issue but I wanted to re-raise. Simply if a connection cannot be made to a DB, for example a firewall is blocking the attempt my script will just hang forever. I've looked around at the docs and stack overflow and a lot of people seem to be reporting the keyword doesn't work / is ignored.

    For example:

    try:
            conn = pyodbc.connect(CONN_STRING,timeout=5)
    except:
            print "Connetion to Database timed out"
            sys.exit(1)
    
    opened by ltoshea 35
  • ('01000',

    ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 17 for SQL Server' : file not found (0) (SQLDriverConnect)")

    Hi guys, I already had a look at previous similar issues but I could not find a proper solution. I am using a Jupyter notebook on Azure ML compute instance. I am trying to connect an Azure SQL database using pyodbc but I get below error: _('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 17 for SQL Server' : file not found (0) (SQLDriverConnect)")_

    My code:

    import pyodbc
    server = 'tcp:xxx.database.windows.net'
    database = 'xxxx'
    username = 'xxx'
    password = 'xxxxx'
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
    cursor = cnxn.cursor()
    

    Environment

    • Kernel: Python 3.6 Azure ML
    • Python: 3.6.9 |Anaconda, Inc. [GCC 7.3.0]
    • pyodbc: 4.0.27
    • OS: 16.04.6 LTS (Xenial Xerus)
    • DB: Azure SQL
    • driver: ODBC Driver 17 for SQL

    Issue

    Expected behaviour: I expect to have a successfull connection, Observerd behaviour: No connection to the DB because it can not locate ODBC Driver 17 for SQL.

    Extra information from similar questions online: 1- There is no microsoft folder in /opt folder (referringthis question and solutions) 2- There is no odbcinst file in /etc folder (referring this question and solutions) 3- When I try pyodbc.drivers() it returns an empty array. (I uninstalled and reinstalled pyodbc, I am able to import it.) 4- I can not locate msodbcsql17 (referring here) 4- I tried ODBC Driver 13 as well, same problem exists.

    Any help will be appreciated!

    opened by vefae 33
  • Need a way to define data type/length when passing variables in SQL Server

    Need a way to define data type/length when passing variables in SQL Server

    I'm doing selects/inserts/updates on my tables and SQL Server is creating an execution plan for every permutation of character lengths that the selects/inserts/updates into the table from python.

    I believe this is causing some issues with the performance of the db and may create some memory issues.

    I would like to be able to set the data type/length when passing parameters. Ideally, pyodbc would know the datatype/length before inserting and set them accordingly but I don't know if this will create more issues issues than it will solve, so being able to define them myself might help.

    More specifically, when I run a trace, this is what I see:

    declare @p1 int
    set @p1=4882452
    exec sp_prepexec @p1 output,N'@P1 nvarchar(11),@P2 nvarchar(16)',N'SELECT TOP 1 C_KEY FROM C WHERE A_NM = @P1 AND C_NM = @P2',N'Zantesuken1',N'RasalhagueLegacy'
    select @p1
    

    and when looking at the execution plans, I find that an execution plan has been created for every single permutation of these selects.

    Perhaps something like this:

    cursor.execute("SELECT X FROM Y WHERE Z1 = ? AND Z2 = ?", param1.type(varchar(50)), param2.type(bigint))

    No idea if this makes sense and maybe this is already possible somehow and I don't know about it, so let me know if there's a way around this issue.

    edit Also noticed that the auto-incrementing @p1 seems to be going up really quickly (I'm doing a lot of transactions). Is there any way to reset this counter? I've tried deleting the cursor, closing the connection, but nothing seems to be working.

    opened by ZaM-Rai 32
  • No Error Message - using pyodbc.connect() on an Access DB Linked to a SharePoint List

    No Error Message - using pyodbc.connect() on an Access DB Linked to a SharePoint List

    Environment

    • Python: 3.6.6 64bit
    • pyodbc: 4.0.27
    • OS: Windows 10 Enterprise
    • DB: Microsoft Access DB Linked to Sharepoint 2016 List
    • driver: Not sure how to check this. Please advise if this info is important.

    Issue

    I have two .accdb files. One is called Test.accdb, the other is called Test2.accdb.

    Test.accdb is linked to a Sharepoint 2016 List. Test2.accdb is not linked to anything.

    I am having issues setting up a conn variable.

    I am assigning conn as follows:

    conn = pyodbc.connect(r'Driver={Microsoft Access Driver (*.mdb, *.accdb)}; DBQ=C:\\Users\\userName\\Desktop\\Project Folders\\sharepointList\\test.accdb;')
    

    When I run that line of code with test2.accdb as the file to connect to I have no issues. The line completes and I can run the rest of my code.

    When I run the line of code with test.accdb, the one linked to Sharepoint, I can not get past it. I wrote a small amount of code to test a theory. It is shown below:

    print("Before")
    conn = pyodbc.connect(r'Driver={Microsoft Access Driver (*.mdb, *.accdb)}; DBQ=C:\\Users\\userName\\Desktop\\Project Folders\\sharepointList\\test.accdb;')
    print("After")
    

    I also tried the following, using try/except:

    try:
        print("Before")
        conn = pyodbc.connect(r'Driver={Microsoft Access Driver (*.mdb, *.accdb)}; DBQ=C:\\Users\\userName\\Desktop\\Project Folders\\sharepointList\\test.accdb;')
    except:
        print("Something Crashed")
    print("After")
    

    The new print statement was never executed. This leads me to believe that the code never really crashed, It just sort of stopped.

    When I run this code with test2.accdb both print lines are executed. When I run this code with test.accdb, the one linked to sharepoint, only the "Before" print line is executed. I would expect the conn assignment to execute completely and allow me to execute the rest of my code. Instead, the code stops running at some point within the .connect() function. I get no error message when I run the code. The code simply stops.

    opened by Bigbigyoshi 31
  • pyodbc.ProgrammingError on Complex Queries

    pyodbc.ProgrammingError on Complex Queries

    • Python: 2.7.15 x86
    • pyodbc: 4.0.24
    • OS: Windows 10/Ubuntu 16.04
    • DB: MS SQL Server 2017
    • driver: FreeTDS 1.0.9

    Issue

    I have some complex T-SQL queries that have multiple commands like this:

         declare @fim date
    			IF (OBJECT_ID('[dbo].[fnUTCDateTB]') IS NOT NULL)
    				SET @fim = (select dateadd(day,-4,convert(date,DataLocal)) from [dbo].[fnUTCDateTB](GETDATE()))
    			ELSE
    				SET @fim = dateadd(day,-4,convert(date,getdate()))
    			 SELECT CST.service_id as service_id
    			     ,  CST.ID as customer_id
    		    	 ,  CFG.ID as customer_config_id
    		    	 ,  CASE cct.frequency_type
                      		WHEN 'DAY'   THEN DATEADD(DAY  , cct.frequency_quantity * cfg.cycle_number, cfg.birthday)
                            WHEN 'MONTH' THEN DATEADD(MONTH, cct.frequency_quantity * cfg.cycle_number, cfg.birthday)
                            WHEN 'YEAR'  THEN DATEADD(YEAR , cct.frequency_quantity * cfg.cycle_number, cfg.birthday)
                        END as next_birthday
    		      FROM  CUSTOMER cst (NOLOCK)
    

    which used to work with pymssql without any problem. Later we had to switch to PyODBC because we needed to connected to an AlwaysOn secondary database, and this required the ApplicationIntent=ReadOnly parameter. I configured it by compiling and installing the latest FreeTDS plugin with ODBC. I tested it with tsql and isql tools, in addition to MS SQL Management Studio 17 and JetBrains DataGrip, and the queries worked as expected. The problem only happens with my Python script using PyODBC. I get this error with complex queries:

    first_row = cur.fetchone()
    

    pyodbc.ProgrammingError: No results. Previous SQL was not a query.

    If I test with short queries they would work even with @DECLARE statements, while long queries work only replacing when removing the @DECLARE statements and substituting all the variables inside the query with their values.

    I hope that you can give me a tip on how I can solve that.

    Environment or Driver Issue 
    opened by ahmedyarub 30
  • pip install pyodbc fails on Windows

    pip install pyodbc fails on Windows

    this fails consistently on 2 different machines one Windows Server 2012R2 and one Win8.1 the error is the same.

    C:\Windows\System32>pip install pyodbc Collecting pyodbc Using cached pyodbc-3.0.10.tar.gz Installing collected packages: pyodbc Running setup.py install for pyodbc Complete output from command "c:\program files (x86)\python 3.5\python.exe" -c "import setuptools, tokenize;file='C:\Users\Kiril\AppData\Local\Temp \pip-build-wx_guj66\pyodbc\setup.py';exec(compile(getattr(tokenize, 'open', o pen)(file).read().replace('\r\n', '\n'), file, 'exec'))" install --recor d C:\Users\Kiril\AppData\Local\Temp\pip-0hu94gdr-record\install-record.txt --sin gle-version-externally-managed --compile: running install running build running build_ext building 'pyodbc' extension error: [WinError 2] The system cannot find the file specified

    ----------------------------------------
    

    Command ""c:\program files (x86)\python 3.5\python.exe" -c "import setuptools, t okenize;file='C:\Users\Kiril\AppData\Local\Temp\pip-build-wx_guj66\py odbc\setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().re place('\r\n', '\n'), file, 'exec'))" install --record C:\Users\Kiril\AppData \Local\Temp\pip-0hu94gdr-record\install-record.txt --single-version-externally-m anaged --compile" failed with error code 1 in C:\Users\Kiril\AppData\Local\Temp
    pip-build-wx_guj66\pyodbc

    C:\Windows\System32>

    Investigating 
    opened by kirilan 29
  • fatal error: sql.h: No such file or directory

    fatal error: sql.h: No such file or directory

    when pip install pyodbc got error #include <sql.h> ^~~~~~~ compilation terminated. error: command 'gcc' failed with exit status 1

    ----------------------------------------
    

    Command "/usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-install-e89qqq9z/pyodbc/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-record-_itwd76b/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-e89qqq9z/pyodbc/

    opened by Roland4444 28
  • Mac M1 ODBC Driver 18 for SQL Server

    Mac M1 ODBC Driver 18 for SQL Server

    Please first make sure you have looked at:

    • Documentation: https://github.com/mkleehammer/pyodbc/wiki
    • Other issues

    Environment

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: 3.11
    • pyodbc: 4035
    • OS: Ventura 13.1
    • DB:database.windows.net
    • driver: ODBC Driver 18 for SQL Server

    Issue

    Often it is easiest to describe your issue as "expected behavior" and "observed behavior".

    File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/sqlalchemy/engine/default.py", line 598, in connect return self.dbapi.connect(*cargs, **cparams) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sqlalchemy.exc.OperationalError: (pyodbc.OperationalError) ('08001', '[08001] [Microsoft][ODBC Driver 18 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)') (Background on this error at: https://sqlalche.me/e/14/e3q8)

    Environment or Driver Issue 
    opened by Nuckeln 6
  • cursor in bad state after executing statement with print statement and really long input

    cursor in bad state after executing statement with print statement and really long input

    Please first make sure you have looked at:

    • Documentation: https://github.com/mkleehammer/pyodbc/wiki
    • Other issues

    Environment

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: 3.11 64-bit
    • pyodbc: 4.0.35
    • OS: Windows 10
    • DB: SQL Server 2019 (15.0.4123.1)
    • driver: ODBC Driver 18 for SQL Server (2018.181.02.01)
    • SQL.LOG

    Issue

    The PRINT statement is not getting outputed. (see https://github.com/mkleehammer/pyodbc/wiki/Cursor#messages). It will work if I make input less than 2070 characters.

    cnxn = pyodbc.connect(cnxn_str, autocommit=True)
        crsr = cnxn .cursor()
        input = '165,2900,3123,6135,2025,1117,5673,1889,7452,6652,4088,6837,6104,4129,676,6013,5963,4516,2947,1408,255,1859,7205,3747,3553,123,6446,357,1403,1091,2140,3397,3774,5924,3379,3436,6043,1194,5618,1406,1081,4120,2252,6751,3765,826,2645,949,2993,5718,1043,2316,4438,2535,7165,6562,4436,121,7429,4433,2610,663,832,6941,3554,3698,120,6920,3077,5965,2809,527,6566,4548,3929,6724,7228,2098,119,5771,1264,5843,1508,1075,5623,1239,4338,6787,7406,6569,4190,1683,2538,1415,6672,3521,3295,118,6615,1827,6406,7329,6831,7328,3534,849,2002,5746,2742,6549,7439,6892,2082,2042,1667,7446,2192,897,3428,1435,2487,780,117,6418,1858,2016,1193,3566,1237,4525,2085,1068,6369,2049,487,494,4362,846,1646,1588,875,793,6778,6177,1067,5708,712,7414,5973,4074,3832,3571,116,6594,3287,2870,3419,3174,115,4428,4124,1823,2422,3352,540,5863,2228,1714,2143,6195,5977,3894,545,5998,6755,6253,6847,1350,4515,2666,1929,7095,114,7061,3167,6689,6185,5722,7293,6834,6354,4421,6630,113,3565,3551,661,3307,1344,5717,7072,3114,7497,1184,3454,878,468,2188,6085,7071,112,4471,4331,2668,3533,7212,461,6946,7269,3550,6545,1005,3862,716,4205,1341,3976,6074,585,2287,3582,7221,3735,5643,3343,1551,2648,5695,353,3612,1850,1573,7006,1145,6824,6246,6669,703,4081,6070,3350,6067,3135,6184,5940,2927,5857,2581,2390,4295,6157,950,7110,7294,3275,3986,7113,4313,1739,1092,7495,6126,5855,3824,5839,6226,3069,2663,6722,5831,3705,5941,111,3786,1965,6441,6602,856,6140,4158,3610,6242,2170,1887,4429,1108,6404,3327,2251,1141,4100,7344,7342,2858,7343,110,4330,3062,1796,5671,4378,800,2539,6848,109,4150,5850,3090,3362,2385,1623,6927,3763,1263,2334,7167,7203,1487,6025,7411,2102,5644,3730,2722,1778,814,2104,1595,5794,635,4184,5881,3548,3048,6932,1574,6049,2320,3543,1387,5936,7079,108,7408,3497,3959,1389,1262,5574,3098,2341,2165,5680,3485,4430,1730,6329,7451,1757,7196,6179,107,2401,6411,6165,1012,1061,2642,5847,1585,2086,2081,6678,5575,6172,1727,6676,2807,2091,6655,3969,1795,4505,5915,5571,5674,2951,3253,4449,3120,499,105,104,103,4445,102,6805,6467,1177,3480,2670,101,753,475,1111,864,100,3517,5584,5804,1235,5960,6934,2957,1444,3477'
        crsr.execute("PRINT 'HI';SELECT ?", [input])
        print(crsr.messages)
    

    Often it is easiest to describe your issue as "expected behavior" and "observed behavior".

    opened by hb2638 1
  • various setup.py tweaks

    various setup.py tweaks

    Some tidy-up work on setup.py:

    • Better to use shlex.split() instead of just plain str split() when parsing unix-style (posix-style) parameters (lines 234, 237). Plain split() will not correctly parse parameter values with spaces in them (e.g. echo "Hello world!").
    • If odbc_config is not available at line 205, then there would be no stdout and the unpacking at line 206 would fail.
    • Best not use dir as a variable at line 222 because it's a built-in function. Not an actual problem here because dir is in its own namespace within the list comprehension but still.
    • Bump the pyodbc package version in setup.py. Version 4.0.35 has been-and-gone now so we should be concentrating on version 4.0.36 (or perhaps 5.0.0).
    • General linting. This was largely done by Kleehammer in this commit but somehow it got reverted.
    opened by keitherskine 0
  • Drop official support for Python 2.7 and 3.6

    Drop official support for Python 2.7 and 3.6

    This is a potential minimalistic PR for dropping official support for Python 2.7 and 3.6. This PR does not remove any 2.7 code but it would at least mark a formal transition to the Python 3.7+ only version of pyodbc.

    opened by keitherskine 0
  • database-specific unit test folders, updated test scripts

    database-specific unit test folders, updated test scripts

    Note, this PR will not work with Python 2.7! Do not merge until pyodbc no longer supports Python 2.7.

    The most significant part of this PR is that the unit test scripts have been moved into database-specific folders. There is now a separate folder for each database. The pytest utility is now directed to the relevant folder to find ("discover") all the unit tests for a specific database. Hence, in the future, new unit tests can be added to the relevant database folder simply as brand new scripts, rather than having to add the tests to the existing database-specific test script. pytest will find them all.

    Other updates:

    • Python 2.7 and 3.6 are dropped from the CI scripts (but this PR assumes they are already no longer supported)
    • the Ubuntu build tests now use the new run_tests() utility function, so that all tests happen from one command
    • for the Windows build tests on Appveyor:
      • SQL Server 2019 is now used (instead of SQL Server 2017)
      • PostgreSQL 13 is now used (instead of PostgreSQL 11 which is rather old now), including the drivers
      • the latest MySQL 8.0 drivers are now used
      • the updated run_tests() utility function is used to run tests
      • the build package is used to generate wheels instead of setup.py, to be more PEP517-compliant

    Notes:

    • The unit test scripts have not been changed to use "pytest" style unit tests. The scripts still use "unittest" style unit tests. That work will be the subject of a later PR.
    • When Python 2.7 is dropped, the "tests2" folder will be deleted and the "tests3" folder will be renamed to just "tests". At that point, the testing code will have to be updated accordingly.
    opened by keitherskine 0
  • Cannot import `pyodbc` with latest version on Apple Silicon

    Cannot import `pyodbc` with latest version on Apple Silicon

    Environment

    To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

    • Python: 3.10.6
    • pyodbc: 4.0.35
    • OS: macOS Ventura (13.0)
    • DB: N/A
    • driver: N/A

    Issue

    overview: I upgraded my pyodbc version to the latest on PyPi (v4.0.35) and noticed I was getting a new error that I had never dealt with before. Specifically, when importing pyodbc I receive the following:

    (0x0002): symbol not found in flat namespace '_SQLAllocHandle'
    

    An issue for this was raised and closed a while ago; it references this exact problem: #885

    expected behavior: pyodbc should import without issue

    steps to reproduce:

    1. Create new virtual environment and activate:
    python -m venv .venv
    source .venv/bin/activate
    
    1. Install latest pyodbc:
    pip install pyodbc
    
    1. Import pyodbc and observe error:
    python
    >>> import pyodbc
    >>> (0x0002): symbol not found in flat namespace '_SQLAllocHandle'
    
    opened by nleroy917 42
Releases(4.0.35)
  • 4.0.35(Nov 16, 2022)

    This release provides Python 3.11 wheels, plus some other wheel fixes. A special thanks to @keitherskine for the wheel and automated build support that makes this possible.

    There is also an import memory fix when using fast_execute_many. Thanks to @gordthompson for that.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.34(Jul 14, 2022)

    First, I want to say thank you very, very much to the people that setup and maintained the automated building of wheels: @keitherskine, @hugovk, and @abitrolly. This is the first release with wheels for Mac, completely thanks to them. It also saves me a huge amount of time since I no longer have to generate each wheel by hand on different systems.

    Release highlights:

    • Mac wheels are finally here. Thanks to all that worked on the code for that. Please let us know if there are any problems with the wheels on PyPI
    • Python 3.10 wheels are also available
    • Fix for DSNs with non-ASCII characters.
    • Memory leak fix with Decimal parameters.
    • PostgreSQL dates of -Infinity/+Infinity changed to year 1 and 9999 instead of raising an error.
    Source code(tar.gz)
    Source code(zip)
  • 4.0.30(Feb 8, 2020)

    A backwards compatibility bug on Windows was causing "missing DLL" errors and not allowing pyodbc to be loaded (#663). This affected Python versions 3.5+. This was due to building with a compiler that was newer than those used by the official Python builds. The newer Visual Studio 2019 introduced a dependency a new DLL which doesn't ship with Python, so pyodbc would fail to load unless something else had already installed the DLL.

    Keith Erskine added a fix to check for overflow of integer and floating point parameters so that a proper Python exception is raised (#671).

    Kieth and Gord Thompson also provided a bunch of improvements for unit tests.

    Anatoli Babenia updated the readme with a badge for PyPI which provides a quick link to it. Very nice. PyPI should now also include the contents of the readme instead of just a single sentence thanks to a commit by Keith.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.28(Dec 21, 2019)

    Fixes in this release:

    • Fix incorrect size calcation for Unicode characters (#654)
    • Fix binding of 32-bit ints on 64-bit Linux (#611)
    • Fixes type mismatch for null/None with table value parameters. #596
    • Fixes and cleanup of unit tests for MS Access (#606), MySQL (#630 #632) and new tests (#637 #645)

    Many thanks to everyone who provided these fixes. Merry Christmas.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.27(Jul 31, 2019)

    • Use int instead of bigint when possible (based on size of data) to work with drivers that don't support bigint at all. Thanks @gordthompson and @v-makouz
    • Support SQL Server datetime2 precision. Previously more data was passed than the column precision causing an error. Thanks @PrinsEdje80, @v-makouz, and @v-chojas
    • Make Informix unit tests work again. Thanks @richard-reece
    • Correct encoding error on big-endian machines for connection errors. Default to native UTF16 instead of UTF16-LE. Thanks @kadler
    • Fix MySQL unit tests. Thanks @gordthompson
    Source code(tar.gz)
    Source code(zip)
  • 4.0.26(Feb 23, 2019)

    This is mostly a bug fix release.

    • Issue #506 uncovered a potentially serious error where Unicode strings may not get a NULL terminator when being converted.
    • Issue #504 was a double decref in the error return path of executemany. Thanks to @v-chojas for this fix.

    Additionally, thanks @gordthompson for both adding get_output_converter (#496) and for updating the SQL Server tests to properly bypass issues not supported with the FreeTDS driver.

    Due to #506, I recommend upgrading from 4.0.25 where the issue was introduced.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.25(Dec 14, 2018)

    Many thanks to the community for this release:

    • Thanks to @v-makouz and @v-chojas , support for SQL Server Table-Valued Paramaters has arrived. See test_tvp in the SQL Server unit tests.
    • Support for IBM DB/2 DECFLOAT type (#472) by @c-dy
    • Better SQL Server and FreeTDS tests with known driver issues (#469) by @gordthompson.
    • Fix "function sequence error" with fast executemany (#450) by @v-makouz.
    Source code(tar.gz)
    Source code(zip)
  • 4.0.24(Aug 15, 2018)

    This is a bug fix release with fixes from lots of contributors:

    • Column size fixed when binding Unicode parameters - noticed when using characters more than 2-bytes wide in UTF-16. Thanks Maxim Kouznetsov.
    • v-chojas fixed use of Unicode connection strings in Python 2.7. Also removed arbitrary limit of connection string lengths.
    • New SQL_CONVERT_X constants added by Jordan Bolton.
    • The setinputsizes method has been overloaded by skeetor and can now accept data types and sizes, not just sizes.
    • v-chojas added support for non-integer-valued connection attributes
    • I cleaned up SQLite unit tests which were out of date and upgraded deprecated unittest methods from all tests. v-chojas made a fix to SQL Server test_drivers test and ensured they run against Python 2.6. (Though, it might be time to officially drop support for older Python versions?)
    Source code(tar.gz)
    Source code(zip)
  • 4.0.23(Mar 30, 2018)

    Some changes in 4.0.22 to integrate the old parameter binding and the new executemany array binding have not handled Unicode in all cases. The integration has been reverted to ensure pyodbc is as stable as possible.

    If you had issues with 4.0.22, please try 4.0.23.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.21(Oct 31, 2017)

    This is a minor release that adds:

    • #286 - constants for setting transaction isolation levels
    • #158 - Cursor.cancel for canceling statements from other threads
    • #289 - Fix type check of connect's encoding keyword in Python 2.7
    • #291 - Specific Python versions added to the PYPI classifiers
    Source code(tar.gz)
    Source code(zip)
  • 4.0.19(Oct 23, 2017)

    Sorry everyone - I left a debug printf statement in the 4.0.18 code. Please use this instead. I'm reproducing the 4.0.18 tag release notes here:


    This is a primarily a fix patch, thought it does contain one new feature that is turned off by default:

    The feature is an optimized Cursor.executemany that binds parameters into an array to drastically reduce network round trips. This can be a major speedup, but this preliminary version is turned off by default because it can only be used with drivers that use UCS-2 exclusively and that properly deal with the ODBC numeric structure. Right now I would recommend only using this with SQL Server on Windows. This feature will be tweaked in the near future to support as many drivers as possible and to use the configured encodings.

    Fixes

    • Add a workaround for building on macOS High Sierra.
    • Add support for building with homebrew unixODBC
    • Fix Unicode error messages that were sometimes garbled in the past.
    • Fix Cursor.columns, primaryKeys, and similar metadata methods that would not allow None passed in for optional keyword parameters such as Cursor.columns('t1', schema=None).
    Source code(tar.gz)
    Source code(zip)
  • 4.0.18(Oct 20, 2017)

    This is a primarily a fix patch, thought it does contain one new feature that is turned off by default:

    The feature is an optimized Cursor.executemany that binds parameters into an array to drastically reduce network round trips. This can be a major speedup, but this preliminary version is turned off by default because it can only be used with drivers that use UCS-2 exclusively and that properly deal with the ODBC numeric structure. Right now I would recommend only using this with SQL Server on Windows. This feature will be tweaked in the near future to support as many drivers as possible and to use the configured encodings.

    Fixes

    • Add a workaround for building on macOS High Sierra.
    • Add support for building with homebrew unixODBC
    • Fix Unicode error messages that were sometimes garbled in the past.
    • Fix Cursor.columns, primaryKeys, and similar metadata methods that would not allow None passed in for optional keyword parameters such as Cursor.columns('t1', schema=None).
    Source code(tar.gz)
    Source code(zip)
  • 4.0.16(Mar 30, 2017)

    This release adds support for subinterpreters, which fixes crashes in systems like mod_wsgi that run multiple Python interpreters in the same process.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.15(Mar 15, 2017)

    Upgrade ASAP. Previous 4.x versions could cause any parameters passed to SQL statements to live forever by incrementing their reference count.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.14(Mar 4, 2017)

    Fix for #206 where Cursor.fetchall() fails due to a possible bug in PyCodec_Encode. Encoding works correctly but it sets an invalid exception which fetchall() detects.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.13(Feb 25, 2017)

  • 4.0.12(Feb 25, 2017)

    The new pyodbc.drivers() implementation buffer was too small, so names would get truncated.

    Also fixed a potential double-decrement during import, but did not have a case where it crashed.

    Ignore driver-reported max varchar if <=255. Some drivers like FileMaker return -1, etc., which caused a hang when writing.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.11(Feb 19, 2017)

    Added support for reading IBM DB/2 columns as Unicode text.

    Merged in pull request that adds a localhost homebrew directory to the include paths on macOS. Thanks @sgivens0

    Merged in a long-neglected pull request that adds pyodbc.drivers(). Thanks @sergiodlc

    Source code(tar.gz)
    Source code(zip)
  • 4.0.9(Feb 19, 2017)

    Accept UUID objects as parameters. If pyodbc.native_uuid is True, return SQL_GUID columns as UUID objects. If False, the default for backwards compatibility, return them as Unicode strings.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.8(Feb 17, 2017)

    Issue #84 Previously all Python 3 longs were sent via SQL_BIGINT but Access does not support this so now SQL_INTEGER is used when possible. This is also a nice optimization for other drivers.

    Also fixed #195 - Python 3 text and Python 2 unicode was always passed as SQL_WVARCHAR even if the encoding was set to something like UTF-8 that should be SQL_VARCHAR.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.7(Feb 16, 2017)

    Recently a change was made to use SQLDescribeColW so that Unicode column names could be retrieved properly. Unfortunately this uncovered some weirdness with some drivers, this time Teradata.

    I'm not sure if the issue is iODBC (which Apple doesn't ship anymore) is using a 4-byte SQLWCHAR or if Teradata is returning UCS4/UTF-32LE for column names in SQLDescribeColW. Either way I've added a hack that assumes 4-byte chars if the decoding for SQL_WMETADATA (a pyodbc specific constant) is set to any of the UTF-32 encodings. The encoding is then actually used.

    cnxn.setdecoding(pyodbc.SQL_WMETADATA, encoding='utf-32le')
    

    Fixes #194

    Source code(tar.gz)
    Source code(zip)
  • 4.0.5(Feb 11, 2017)

    Fix decoding of Cursor.description column names. Fixes #190 - The issue was a column alias with an i with acute which caused an error. pyodbc now (1) uses the Unicode version of SQLDescribeColumn and (2) uses the configured SQL_C_WCHAR encoding. I've added SQL Server test decode_meta for this.

    When a connection is used in a with clause (as a context manager), the connection has always been committed if successful. However, when an exception is raised it now issues a specific rollback. In the past neither was performed if an exception was raised.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.2(Jan 19, 2017)

  • 4.0.1(Jan 19, 2017)

    This is a doc-only update to replace 4.0.0 which I removed from PyPI (pip). This should be 100% compatible with 4.0.0.

    I was attempting to replace the source tarball for 4.0.0 but that is apparently not allowed. It would have been nice to know that before it let me delete it ;)

    You should upgrade to 4.0.2, however, for some important bug fixes.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.0(Dec 30, 2016)

A framework based on tornado for easier development, scaling up and maintenance

turbo 中文文档 Turbo is a framework for fast building web site and RESTFul api, based on tornado. Easily scale up and maintain Rapid development for RESTF

133 Dec 06, 2022
Script em python para carregar os arquivos de cnpj dos dados públicos da Receita Federal em MYSQL.

cnpj-mysql Script em python para carregar os arquivos de cnpj dos dados públicos da Receita Federal em MYSQL. Dados públicos de cnpj no site da Receit

17 Dec 25, 2022
A Python library for Cloudant and CouchDB

Cloudant Python Client This is the official Cloudant library for Python. Installation and Usage Getting Started API Reference Related Documentation De

Cloudant 162 Dec 19, 2022
db.py is an easier way to interact with your databases

db.py What is it Databases Supported Features Quickstart - Installation - Demo How To Contributing TODO What is it? db.py is an easier way to interact

yhat 1.2k Jan 03, 2023
A tool to snapshot sqlite databases you don't own

The core here is my first attempt at a solution of this, combining ideas from browser_history.py and karlicoss/HPI/sqlite.py to create a library/CLI tool to (as safely as possible) copy databases whi

Sean Breckenridge 10 Dec 22, 2022
A CRUD and REST api with mongodb atlas.

Movies_api A CRUD and REST api with mongodb atlas. Setup First import all the python dependencies in your virtual environment or globally by the follo

Pratyush Kongalla 0 Nov 09, 2022
The Database Toolkit for Python

SQLAlchemy The Python SQL Toolkit and Object Relational Mapper Introduction SQLAlchemy is the Python SQL toolkit and Object Relational Mapper that giv

SQLAlchemy 6.5k Jan 01, 2023
Python client for Apache Kafka

Kafka Python client Python client for the Apache Kafka distributed stream processing system. kafka-python is designed to function much like the offici

Dana Powers 5.1k Jan 08, 2023
#crypto #cipher #encode #decode #hash

🌹 CYPHER TOOLS 🌹 Written by TMRSWRR Version 1.0.0 All in one tools for CRYPTOLOGY. Instagram: Capture the Root 🖼️ Screenshots 🖼️ 📹 How to use 📹

50 Dec 23, 2022
This repository is for active development of the Azure SDK for Python.

Azure SDK for Python This repository is for active development of the Azure SDK for Python. For consumers of the SDK we recommend visiting our public

Microsoft Azure 3.4k Jan 02, 2023
A pandas-like deferred expression system, with first-class SQL support

Ibis: Python data analysis framework for Hadoop and SQL engines Service Status Documentation Conda packages PyPI Azure Coverage Ibis is a toolbox to b

Ibis Project 2.3k Jan 06, 2023
MySQL database connector for Python (with Python 3 support)

mysqlclient This project is a fork of MySQLdb1. This project adds Python 3 support and fixed many bugs. PyPI: https://pypi.org/project/mysqlclient/ Gi

PyMySQL 2.2k Dec 25, 2022
A Pythonic, object-oriented interface for working with MongoDB.

PyMODM MongoDB has paused the development of PyMODM. If there are any users who want to take over and maintain this project, or if you just have quest

mongodb 345 Dec 25, 2022
A Telegram Bot to manage Redis Database.

A Telegram Bot to manage Redis database. Direct deploy on heroku Manual Deployment python3, git is required Clone repo git clone https://github.com/bu

Amit Sharma 4 Oct 21, 2022
Easy-to-use data handling for SQL data stores with support for implicit table creation, bulk loading, and transactions.

dataset: databases for lazy people In short, dataset makes reading and writing data in databases as simple as reading and writing JSON files. Read the

Friedrich Lindenberg 4.2k Jan 02, 2023
Records is a very simple, but powerful, library for making raw SQL queries to most relational databases.

Records: SQL for Humans™ Records is a very simple, but powerful, library for making raw SQL queries to most relational databases. Just write SQL. No b

Kenneth Reitz 6.9k Jan 03, 2023
Asynchronous Python client for InfluxDB

aioinflux Asynchronous Python client for InfluxDB. Built on top of aiohttp and asyncio. Aioinflux is an alternative to the official InfluxDB Python cl

Gustavo Bezerra 159 Dec 27, 2022
Sample code to extract data directly from the NetApp AIQUM MySQL Database

This sample code shows how to connect to the AIQUM Database and pull user quota details from it. AIQUM Requirements: 1. AIQUM 9.7 or higher. 2. An

1 Nov 08, 2021
Use SQL query in a jupyter notebook!

SQL-query Use SQL query in a jupyter notebook! The table I used can be found on UN Data. Or you can just click the link and download the file undata_s

Chuqin 2 Oct 05, 2022
DBMS Mini-project: Recruitment Management System

# Hire-ME DBMS Mini-project: Recruitment Management System. 💫 ✨ Features Python + MYSQL using mysql.connector library Recruiter and Client Panel Beau

Karan Gandhi 35 Dec 23, 2022