pyodbc.cursor.columns doesn't always return table column information

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.7
• pyodbc: 4.0.25
• OS: Docker python:3.7 i.e. Debian 9 (Docker running on MacOS Mojave)
• DB: Netsuite (some Oracle SQL database flavour)
• driver: Netsuite ODBC driver Linux64bit 7.2.0.0050

Issue

I can execute queries against database and get data very reliably. Also getting column description using Cursor.description works fine. The problem is that with Cursor.columns sometimes I get data and sometimes not. When data is available is fully correct. I haven’t been able to draw any specific pattern when it works and when not.

“expected behavior” crsr.columns(table=‘<table_name>’) should return always the column description for the given table

“observed behavior”. crsr.columns(table=‘<table_name>’) sometimes iterator is empty i.e. no data for table columns is available

Simple test code:

def get_table_cols():
    crsr = cnxn.cursor()
    col_count = {}
    for table_name in ['ACCOUNTS', 'COUNTRIES', 'TRANSACTION_LINES', 'SUBSIDIARIES']:
        cols = crsr.columns(table=table_name)
        col_count.update({table_name: len(list(cols))})
    print(col_count)


def loop():
    for x in range(6):
        get_table_cols()


loop()

Output:

{'ACCOUNTS': 33, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 61}
{'ACCOUNTS': 0, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 61}
{'ACCOUNTS': 0, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 0}
{'ACCOUNTS': 0, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 0}
{'ACCOUNTS': 0, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 0}
{'ACCOUNTS': 0, 'COUNTRIES': 0, 'TRANSACTION_LINES': 157, 'SUBSIDIARIES': 0}

[mkleehammer]

This seems to be the same as #506 which is fixed in master but not yet released. If I had put that together I would have closed #506 as a duplicate, but since I posted to patch against it I will close this as a duplicate. If master doesn’t fix it, please reopen this, but I’m pretty sure it will.

[RaiKoHoff]

Attachment: Zip of ODBC Trace files (SUCCESS log (v.4.0.24) and FAIL log (v.4.0.25). Only difference for creating logs: pyodbc.pyd exchanged (v.4.0.24 - v.4.0.25). sql_logs.zip