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

[manrajgrover]

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)')

[gizmo93]

The same here:

Python: 3.5.5
pyodbc: 4.0.23
OS: Windows 10
DB: SQL Server 2017 and 2016
driver: ODBC Driver 13 for SQL Server

tried with SQL Server Native Client too.

Could not determine, where the problem is, but it seems to have to do with string data.

Installed 4.0.22 again and the problems are not there anymore.

[v-chojas]

Could you post a example table schema + Python code to reproduce it, and/or ODBC trace log? That will help with the troubleshooting.

[gizmo93]

Hey @v-chojas

It was happening while trying to insert a pandas dataframe with to_sql.

b64.txt

Thats the dataframe, pickled and base64 encoded.
You can use decoded = pickle.loads(base64.b64decode(encoded)) to turn it back into a dataframe and then you can just use decoded .to_sql() to reproduce the error. (Pandas will create a table itself, if it does not exist).

Error Message: Function sequence error (0) (SQLParamData)

Ahh: It happens only, when fast_executemany is active. Without it (or with the previous release of pyodbc and fast_executemany activated) the inserts won't fail.

[gordthompson]

Reproduced with pyodbc 4.0.23 under 64-bit Python 3.6.4 on Windows 7 with SQLAlchemy 1.2.6. Also confirmed that it is specific to 4.0.23 (4.0.22 works) and is related to string parameter values.

With pyodbc 4.0.23 this works:

import pandas as pd
from sqlalchemy import create_engine, event
cnxn_url = 'mssql+pyodbc://@SQLmyDb'
engine = create_engine(cnxn_url)


@event.listens_for(engine, 'before_cursor_execute')
def receive_before_cursor_execute(conn, cursor, statement, params, context, executemany):
    if executemany:
        cursor.fast_executemany = True

        
table_name = 'fast_executemany_test'
df = pd.DataFrame({'col1':[1, 2]})
df.to_sql(table_name, engine, if_exists = 'replace', chunksize = None)

ODBC trace:
numeric_ok_log.zip

However, if I change the dataframe to contain strings instead of numbers

df = pd.DataFrame({'col1':['foo', 'bar']})

then I get

sqlalchemy.exc.DBAPIError: (pyodbc.Error) ('HY010', '[HY010] [Microsoft][ODBC Driver 11 for SQL Server]Function sequence error (0) (SQLParamData)') [SQL: 'INSERT INTO fast_executemany_test ([index], col1) VALUES (?, ?)'] [parameters: ((0, 'foo'), (1, 'bar'))] (Background on this error at: http://sqlalche.me/e/dbapi)

ODBC trace:
string_fail_log.zip

[gordthompson]

Related issues are being discussed in the Stack Overflow question here.

[v-chojas]

Can you create repro with only the pyODBC calls being made?

I cannot reproduce it with this:

import pyodbc
conn = pyodbc.connect([your connection string here], autocommit=True)
stmt = conn.cursor()
stmt.execute("DROP TABLE IF EXISTS fastexecutemany_test")
stmt.execute("CREATE TABLE fastexecutemany_test([index] BIGINT NULL, col1 VARCHAR(MAX) NULL)")
stmt.fast_executemany = True
stmt.executemany("INSERT INTO fastexecutemany_test([index], col1) VALUES(?, ?)", [[1,'foo'],[2,'bar']])
print stmt.execute("SELECT * from fastexecutemany_test").fetchall()

Values 'foo', 'bar' enter the table correctly.

[gordthompson]

@v-chojas - Before posting I tried to reproduce the issue with plain pyodbc under Python 3.6.4 (Windows, 64-bit) but could not. That's why I went with the pandas code and the ODBC logs in case they gave a hint as to what pandas (or perhaps SQLAlchemy) was doing differently.

[gordthompson]

Also worth noting that this may have some relation to Python_3. I just tried my repro code under Python 2.7.14 (Windows, 64-bit) and using

df = pd.DataFrame({'col1':['foo', 'bar']})

worked without complaint.

[billmccord]

I have the same problem and using Python 2.7.15 didn't fix it for me. I'm using plain pyodbc and getting the issue under Python 2.7.15 and 3.6.5. I tried on both OS X and Windows 10, same result.

[billmccord]

I believe that, at least in my case, the issue is caused by passing an empty string as a param to execute many. I have reproduced it with very simple code (DSN, UID and PWD excluded):

import pyodbc

cnxn = pyodbc.connect(
    'DSN={};UID={};PWD={}'.format(
        DATABASE_DSN,
        DATABASE_USERNAME,
        DATABASE_PASSWORD,
    ))

# Create a cursor from the connection
cursor = cnxn.cursor()

cursor.execute('BEGIN TRY DROP TABLE [test] END TRY BEGIN CATCH END CATCH')

cursor.execute('CREATE TABLE [test]([testcol] [nvarchar](MAX) NULL)')

cursor.fast_executemany = True
cursor.executemany('INSERT INTO [test] VALUES(?)', [['']])

cursor.commit()

For me, this fails using ODBC Driver 17 for SQL Server on Mac and Windows and on Python 2 and 3. There are a number of ways to make this code work:

• Disable fast_executemany
• Change empty string '' to None
• Change empty string '' to a non-empty string

I also added a trace as per this issue, but it didn't seem to be particularly revealing:

[ODBC][7255][1527828468.407527][__handles.c][460]
		Exit:[SQL_SUCCESS]
			Environment = 0x7fbec2829000
[ODBC][7255][1527828468.407719][SQLSetEnvAttr.c][189]
		Entry:
			Environment = 0x7fbec2829000
			Attribute = SQL_ATTR_ODBC_VERSION
			Value = 0x3
			StrLen = 4
[ODBC][7255][1527828468.407890][SQLSetEnvAttr.c][381]
		Exit:[SQL_SUCCESS]
[ODBC][7255][1527828468.407998][SQLAllocHandle.c][377]
		Entry:
			Handle Type = 2
			Input Handle = 0x7fbec2829000
[ODBC][7255][1527828468.408150][SQLAllocHandle.c][493]
		Exit:[SQL_SUCCESS]
			Output Handle = 0x7fbec3810000
[ODBC][7255][1527828468.408722][SQLDriverConnectW.c][290]
		Entry:
			Connection = 0x7fbec3810000
			Window Hdl = 0x0
			Str In = [DSN=xxx;UID=xxx;PWD=xxx][length = 53]
			Str Out = 0x0
			Str Out Max = 0
			Str Out Ptr = 0x0
			Completion = 0
		UNICODE Using encoding ASCII 'US-ASCII' and UNICODE 'UCS-2-INTERNAL'

[ODBC][7255][1527828469.087117][__handles.c][460]
		Exit:[SQL_SUCCESS]
			Environment = 0x7fbec2801800
[ODBC][7255][1527828469.087380][SQLGetEnvAttr.c][157]
		Entry:
			Environment = 0x7fbec2801800
			Attribute = 65002
			Value = 0x7ffee0d200c0
			Buffer Len = 128
			StrLen = 0x7ffee0d200a4
[ODBC][7255][1527828469.087941][SQLGetEnvAttr.c][273]
		Exit:[SQL_SUCCESS]
[ODBC][7255][1527828469.088077][SQLFreeHandle.c][220]
		Entry:
			Handle Type = 1
			Input Handle = 0x7fbec2801800

For now, I can workaround by ensuring that I always use None instead of '', but would appreciate it if someone knows of other workarounds.

[billmccord]

I believe that the issue could be resolved by replacing an empty string with a single space. I tested and it worked on my sample code. I'm not sure if this fix belongs in pyodbc, but it sure would be nice! Please see this SO for more details. In particular, it links to a blog that discusses just this issue.

[jianpan]

We ran into this issue as well. executemany() doesn't seem to handle empty string. Our environment is:

python: 2.7.5
pyodbc: 4.0.23
sqlalchemy: 1.2.5
pandas: 0.18.1
ODBC Driver 17 for SQL Server
Ubuntu 16.04

[tigerhawkvok]

Ran into this, and replacing empty strings with " " doesn't work, either. Pandas was throwing errors trying dbPushable.replace('', None, inplace= True), so I didn't test that.

Running

• Python 3.6
• pyodbc 4.0.23
• Pandas 0.23.0
• ODBC Driver 17 for SQL Server
• Windows 10

Full error:

  File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\core\generic.py", line 1534, in to_sql
    chunksize=chunksize, dtype=dtype)
  File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\io\sql.py", line 473, in to_sql
    chunksize=chunksize, dtype=dtype)
  File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\io\sql.py", line 1156, in to_sql
    table.insert(chunksize)
  File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\io\sql.py", line 670, in insert
    self._execute_insert(conn, keys, chunk_iter)
  File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\io\sql.py", line 645, in _execute_insert
    conn.execute(self.insert_statement(), data)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\base.py", line 948, in execute
    return meth(self, multiparams, params)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\sql\elements.py", line 269, in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\base.py", line 1060, in _execute_clauseelement
    compiled_sql, distilled_params
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\base.py", line 1200, in _execute_context
    context)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\base.py", line 1413, in _handle_dbapi_exception
    exc_info
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\util\compat.py", line 203, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\util\compat.py", line 186, in reraise
    raise value.with_traceback(tb)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\base.py", line 1170, in _execute_context
    context)
  File "C:\ProgramData\Anaconda3\lib\site-packages\sqlalchemy\engine\default.py", line 504, in do_executemany
    cursor.executemany(statement, parameters)
sqlalchemy.exc.DBAPIError: (pyodbc.Error) ('HY010', '[HY010] [Microsoft][ODBC Driver 17 for SQL Server]Function sequence error (0) (SQLParamData)')

[v-chojas]

Please provide an ODBC trace; if you are using Linux/Mac, upgrade to unixODBC 2.3.7pre (available here on GitHub: https://github.com/lurcher/unixODBC/ ) if you are using ODBC Driver 17 since it fixes a logging bug, and otherwise the trace will not contain any useful information.

[veeology]

Not sure if this will help anyone else, but I was able to solve the problem by explicitly encoding the string data as ascii. Using the code provided by @v-chojas earlier in the thread, I am able to reproduce the error with this:

conn = pyodbc.connect([your connection string here], autocommit=True)
stmt = conn.cursor()
stmt.execute("DROP TABLE IF EXISTS fastexecutemany_test")
stmt.execute("CREATE TABLE fastexecutemany_test([index] BIGINT NULL, col1 VARCHAR(MAX) NULL)")
stmt.fast_executemany = True
stmt.executemany("INSERT INTO fastexecutemany_test([index], col1) VALUES(?, ?)", [[1,'foo'],[2,'bar']])
print (stmt.execute("SELECT * from fastexecutemany_test").fetchall())

Result:

Error: ('HY010', '[HY010] [Microsoft][ODBC Driver 13 for SQL Server]Function sequence error (0) (SQLParamData)')

But explicitly encoding the string data as ascii allowed the code to execute correctly. This is the code I used:

stmt.executemany("INSERT INTO fastexecutemany_test([index], col1) VALUES(?, ?)", [[1,'foo'.encode('ascii')],[2,'bar'.encode('ascii')]])
print (stmt.execute("SELECT * from fastexecutemany_test").fetchall())

Result:

[(1, 'foo'), (2, 'bar')]

Environment:
Python 3.6
pyodbc 4.0.23
connecting to an Azure-SQL database (ODBC Driver 13 for SQL Server)
Windows 7, 64-bit

[logicalextreme]

I can also confirm that this affects pyodbc 4.0.23 but not 4.0.22.

Explicitly encoding the string value as @veeology mentioned works for me, though I also need to change empty strings to None as @billmccord said — not really viable if you're hoping to preserve the distinction between empty strings and NULLs (I'm pushing data from a pyodbc MySQL cursor to a pyodbc SQL Server cursor).

However I've made two further observations:

• this only happens to columns declared with the varchar(max) and nvarchar(max) data types; you can confirm this by changing your (max) column length to 8000 or 4000 (or less) respectively
• HY010 doesn't happen if the params value is a generator object, but definitely happens if it's a sequence; however I believe that fast_executemany behaviour doesn't occur with a generator/non-sequence as performance completely tanks when attempting to do so

My guess then is that 4.0.23 is no longer automatically preparing parameter values as binary for (max) columns during fast_executemany operations. This would be explained by my two observations here and @veeology's workaround, though the empty string thing confuses me.

I'm personally reverting to 4.0.22 as I have to write a fair bit of extra code to work around this and it incurs a performance penalty of about 25%. However if anybody does use @veeology's workaround for 4.0.23, I think you'll be wanting to encode in utf_16_le for nvarchar(max) columns and you're probably safest (codepage-wise) with utf8 for varchar(max), based on the docs here.

My setup:

Win10
ODBC Driver 17 for SQL Server (64-bit)
Python 3.6.5 and 3.7.0, both Windows 64-bit

[billmccord]

I had been running on my Mac with 4.0.23 and everything was working fine using spaces instead of empty strings, but then I pushed my code to a Windows 2016 server and I'm seeing issues both with the original code I posted above and even if I change the empty string to a space.

The good news is that since I'm on Windows I was able to get a decent ODBC trace log.
SQL.LOG

Setup:
Windows Server 2016
ODBC Driver 17 x64 2.0.1
Python 3.6.6

I hope this helps to track down the issue! I suppose I will also revert to 4.0.22 as per @logicalextreme recommendation for now...

[v-chojas]

Thanks for the trace. It appears that pyODBC is calling SQLParamData twice without ever actually sending the data for the parameter with SQLPutData. I will investigate this.

[v-chojas]

I have determined that it is caused by small bug in the code, which is not sending 0-length parameters. Try the fix here: #425

[billmccord]

OK, I had rolled back to 4.0.22 in order to resolve this issue, but it looks like when I run with 4.0.22 something goes screwy when I insert data. When I retrieve the inserted data, it has a bunch of '\x00' characters in between the characters of a bunch of varchars in the database. It's really weird and doesn't happen with version 4.0.23.

Any chance you can make another release with the #425 fix?

[logicalextreme]

@billmccord you're not encoding the strings to utf_16_be by any chance, are you?

[billmccord]

Not intentionally, but I'm not specifying an encoding anywhere. The database is the default encoding. I ran a test where I insert data and retrieve and compare. Run with 4.0.22 the test has the weird characters. Run with 4.0.23 it doesn't.

[v-chojas]

Any chance you can make another release with the #425#425, Fix DAE for 0-length parameters fix?

@mkleehammer

[billmccord]

Tried pip installing the commit and keep getting errors. I tried:
pip install git+git://github.com/mkleehammer/pyodbc.git@72a3b404d8df714c6326459cc735d9ca21215f6f

AND

pip install git+ssh://git@github.com/mkleehammer/pyodbc.git@72a3b404d8df714c6326459cc735d9ca21215f6f

But I'm getting the following error:

fatal: reference is not a tree: 72a3b404d8df714c6326459cc735d9ca21215f6f
Command "git checkout -q 72a3b404d8df714c6326459cc735d9ca21215f6f" failed with error code 128 in /private/var/folders/2b/jlr73wzj0_d9tv3b3vt37vb80000gn/T/pip-req-build-oqsz29i2

Any help or suggestions you can provide would be appreciated. I have a project that is already way overdue because of all the issues encountered.

[billmccord]

Never mind, I see that it is in a different repo, sorry about that. I'll try there.

[billmccord]

Alright, I finally got the pull request that @v-chojas sent to build on Windows. Originally, I had observed that when I ran my test program on my Mac it was working. However, I just tried it on Windows after doing a manual build and I still get the following error when trying to executemany and it doesn't matter if I use an empty string or a single space:
pyodbc.Error: ('HY010', '[HY010] [Microsoft][ODBC Driver 17 for SQL Server]Function sequence error (0) (SQLParamData)')

It seems the problem is still not fixed on Windows. Please find the ODBC log attached.

SQL.LOG

[billmccord]

I just noticed that it actually doesn't matter what the string is that is input on Windows. If I change it to 'test' rather than an empty string I still get the same error. If I disable fast_executemany then all of my tests work (empty string or non-empty string). So, it appears that fast_executemany is just broken on Windows.

[logicalextreme]

Yep, I'm seeing no difference between 4.0.23 and the commit from the pull request on Windows. The (max) datatypes just don't work on empty strings (None gives NULL) and you need to explicitly encode nonempty strings to a suitable encoding for the datatype. The below (apologies for the code quality, I'm in work) shows what works and what doesn't; everything works in 4.0.22 but the same 8 conditions cause the HY010 exception in both 4.0.23 and the fix for #425 :

import pyodbc
with pyodbc.connect(f"driver={{odbc driver 17 for sql server}};app=py;server=.\sql2017;trusted_connection=yes") as cx:
    with cx.cursor() as cs:
        cs.fast_executemany = True
        for dt in "varchar(8000)", "nvarchar(4000)", "varchar(max)", "nvarchar(max)":
            for val in None, "", " ", "a":
                for enc in "", {"v":"utf8", "n":"utf_16_le"}[dt[0]]:
                    prm = val.encode(enc) if enc and val else val
                    if not all([val is None, enc]):
                        try:
                            cs.executemany(f"declare @ {dt}; set @ = ?", [[prm]])
                            res = "OK"
                        except Exception as err:
                            res = err
                        oval = "None" if val is None else f"'{val}'"
                        print(f"{dt:15} {oval:6} {enc:11} {res}")

[v-chojas]

Please try PR #467

[maki-markie]

still not working my requirements:
Package Version

---

python 3.7.0
numpy 1.14.5
pandas 0.23.3
pip 18.1
pyodbc 4.0.24
python-dateutil 2.7.3
pytz 2018.5
setuptools 39.0.1
six 1.11.0
SQLAlchemy 1.2.10

[gordthompson]

@maki-markie - Did you install from the code on GitHub? Your list says pyodbc 4.0.24, which does not include the fix in #467.

[maki-markie]

@gordthompson No, i just did a normal pip install. Is there another instruction how to install it?
thanks
edit: i downloaded the pyodbc-master.zip can you guide me from here how to install it? sorry im very new to this.

[maki-markie]

still having some trouble after installing the : pyodbc 4.0.0-unsupported
pyodbc.Error: ('HY000', '[HY000] [Cache ODBC][State : HY000][Native Code 400]\r\n..\\venv\\Scripts\\python.exe]\r\n[SQLCODE: <-400>:<Fatal error occurred>]\r\n[Cache Error: <<VALUE OUT OF RANGE>%0AmBs1+1^%sqlcq.SPEDITION.cls136.1>]\r\n[Location: <ServerLoop - Query Fetch>]\r\n[%msg: <Unexpected error occurred: <VALUE OUT OF RANGE>%0AmBs1+1^%sqlcq.SPEDITION.cls136.1>] (400) (SQLGetData)')

[v-chojas]

@maki-markie What ODBC driver are you using? That message does not look familiar.

[gordthompson]

@maki-markie - Are you working with a Caché database?

[maki-markie]

@gordthompson hi, sorry for the late reply. yes i am working with cache database. do you have any experience with this? thanks

[MrMathias]

@gordthompson #467 seems to relate more to null values than empty string values. I am testing it now.

Best workaround so far seems to be to replace empty strings with null or whitespace.

[gordthompson]

@logicalextreme re: "I believe that fast_executemany behaviour doesn't occur with a generator/non-sequence"

That does seem to be the case. Details in issue #500

[mkleehammer]

Did that answer the question? Should we close this and pursue #500?

[gordthompson]

Yes, I'd say that this can be closed. #467 addressed the main issue; the mention of #500 was just a tangent resulting from an earlier comment.

[eddyizm]

I've been watching this thread for several months and still not able to use the fast execute.
I am on the latest version . Do I need any other packages updated? I'm googling for a work around but I'm wary of having to maintain those going forward.

Name: pyodbc
Version: 4.0.25

(pyodbc.Error) ('HY090', '[HY090] [Microsoft][ODBC Driver Manager] Invalid string or buffer length (0) (SQLBindParameter)')

EDIT: Nevermind. I found the issue with the ODBC driver, was using an obsolete one and downloaded the latest to fix the issue. Thanks!~

[eddyizm]

@maki-markie Check your sql driver once you get the latest pyodbc. I would bet that is where the issue lies.

[v-chojas]

@eddyizm he is not using SQL Server, but I would not be surprised if the ODBC driver does not support parameter arrays; fast_executemany was originally designed for and works best with ODBC Driver 17 for SQL Server, although it may also be usable with other drivers.

[Puneeth2]

I am Trying to insert the data from CSV file to SQL server dynamically using python below is the code
with open (FILENAME, 'r') as f:
#reader = csv.reader(f)
reader = csv.reader(f, delimiter=',',lineterminator='\r\n', quoting=csv.QUOTE_NONNUMERIC)
data = next(reader)
#query="Bulk INSERT " + ShortName + " From = " + infile + " with(FIELDTERMINATOR =',')"
query="INSERT into " + ShortName + " values ({0})"
#print(query)
query = query.format(','.join('?' * len(data)))
cursor_Sql = cnxn.cursor()
cursor_Sql.execute(query, data)
for data in reader:
cursor_Sql.execute(query, data)
cursor_Sql.commit()

But i am getting the pyodbc.Error: ('07002', '[07002] [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error (0) (SQLExecDirectW)') error can any one please help this?

[gordthompson]

@Puneeth2 - Your question does not appear to be related to the behaviour of pyodbc itself, so you might have better luck getting an answer on Stack Overflow.

[selvakarna]

sql server cannot find ? using python from Linux OS?

SQL Server ---in Windows OS
my application run----Linux OS?

How to solve ?sql server cannot find

[gordthompson]

@selvakarna - Your question does not appear to be related to this particular issue. Try asking for help on Stack Overflow.

[diegoaranas]

I came across this bug recently.

Python: 3.7.3
pyodbc: 4.0.26
pandas: 0.24.2
SQLAlchemy: 1.3.5
OS: Windows 10
driver: ODBC Driver 17 for SQL Server

[nrhead]

I'm having the same issue as well. I've installed the pyodbc version in #467. My pyodbc version is 4.0.18b89.

[gordthompson]

@nrhead - Try upgrading pyodbc to version 4.0.27.

[hishamsajid]

Upgraded to version 4.0.27 and explicitly encoded the object type columns to ascii, it seems to be working now.

for col,dtype in tbl_df.dtypes.iteritems():
    if(dtype=='object'):
        tbl_df[col] = tbl_df[col].str.encode('ascii')

[ethan-deng]

Same issue with 4.0.27
Python: 3.7.3
pyodbc: 4.0.27
OS: Windows 10
driver: ODBC Driver 17 for SQL Server

[gordthompson]

@ethan-deng - Please open a new issue and include an MCVE that clearly illustrates the specific problem you are currently seeing.

[ethan-deng]

The solution of #617

and install the bug fix helps.

pip install git+https://github.com/v-makouz/pyodbc.git@bugfix_unicode_size --user

[keitherskine]

Closed due to inactivity.

[Ephafrus]

Solution is to go to the ODBC Driver created, change character format from utf-8 to ASCII. Keep changing and testing. There is server miscommunication due to character set.