MS Access .fetchall() falls into infinite loop. Same script works in pyodbc

[TrentonBush]

Hello, thanks for creating this package, I'm excited to use your numpy integration features. Unfortunately I haven't gotten turbodbc to read data the way I expect, because fetchall() falls into an infinite loop.

I am trying to read an old Access .mdb with the 64-bit 2010 Access Engine driver on Windows 7.

I executed the following script with both turbodbc and pyodbc, and only turbodbc has the looping problem with .fetchall(). The .fetchone() works just fine. I also tried toggling prefer_unicode with no effect. Log files are attached. I'm brand new to ODBC and a beginner with python, so my apologies if I've done something silly.

Any help appreciated!

from turbodbc import connect, make_options
connstr = (
    r"Driver={Microsoft Access Driver (*.mdb, *.accdb)};"
    r"DBQ=C:\filepath\database.mdb;"
)
options = make_options(prefer_unicode=True)
connection = connect(connection_string=connstr, turbodbc_options=options)
cursor = connection.cursor()
cursor.execute('SELECT column_name FROM my_table')
cursor.fetchone()
cursor.fetchall()

Here is the part of the log file that loops:

kernel-f124ea1a 16a4-2390	ENTER SQLFetchScroll 
		SQLHSTMT            0x000000000058F8B0
		SQLSMALLINT                  1 <SQL_FETCH_NEXT>
		SQLLEN                     0

kernel-f124ea1a 16a4-2390	EXIT  SQLFetchScroll  with return code 100 (SQL_NO_DATA_FOUND)
		SQLHSTMT            0x000000000058F8B0
		SQLSMALLINT                  1 <SQL_FETCH_NEXT>
		SQLLEN                     0

pyODBC.LOG turbODBC.LOG

[MathMagique]

Hi Trenton! Thanks for your kind words and the issue report. There is no inherent difference between fetchall() and fetchone(). In fact, fetchall() repeatedly calls fetchone() internally. Also, I cannot find anything silly in what you do.

It seems like you have run into a compatibility issue similar to #158. Maybe turbodbc is making an illegal assumption of how drivers should signal that no more data is there that seems to be satisfied with the integration databases that are used for development. That would require a closer look.

As a workaround, you could try a different ODBC driver (for example the one from easysoft, if possible.