Error whne reading table has nearly 100 fields

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Execute query
2. Fetch row 

What is the expected output? What do you see instead?
Bus error

What version of the product are you using? On what operating system?
pyodbc-3.0.2-1.x86_64 on Opensuse 64b

Please provide any additional information below.
I run a query on a table that has several field, it's ok, but if i run it on a 
table that has more than 80 fields, i got error , i think it's a memory error. 
So can you show me how to solve that kind of problem ?
In my system, there are a lot of such tables. 

Original issue reported on code.google.com by SieuT...@gmail.com on 28 Nov 2012 at 3:15

[GoogleCodeExporter]

I can confirm this on pyodbc 3.0.6 running on Ubuntu 14.

1. Occurs with a 'SELECT *' or 'SELECT <columns...>' on a VIEW that has 14 
columns.
2. Does not occur when I restrict the columns to less than the full amount.
3. Occurs even when I use 'WHERE ROWNUM < 2' to restrict the result set.
4. Occurs with certain columns, e.g. one with data type DECIMAL(18,0).

From 4, it seems to be related to specifics of some columns, not number of 
columns per se.

GDB gives me:
{{{
Program received signal SIGBUS, Bus error.
0x00007ffff687f98c in GetData(Cursor*, long) () from 
/usr/lib/python2.7/dist-packages/pyodbc.so
(gdb) bt
#0  0x00007ffff687f98c in GetData(Cursor*, long) () from 
/usr/lib/python2.7/dist-packages/pyodbc.so
#1  0x00007ffff6880e49 in ?? () from /usr/lib/python2.7/dist-packages/pyodbc.so
#2  0x00007ffff6880f11 in ?? () from /usr/lib/python2.7/dist-packages/pyodbc.so
#3  0x000000000052d432 in PyEval_EvalFrameEx ()
#4  0x000000000055c594 in PyEval_EvalCodeEx ()
#5  0x00000000005b7392 in PyEval_EvalCode ()
#6  0x0000000000469663 in ?? ()
#7  0x00000000004699e3 in PyRun_FileExFlags ()
#8  0x0000000000469f1c in PyRun_SimpleFileExFlags ()
#9  0x000000000046ab81 in Py_Main ()
#10 0x00007ffff7817ec5 in __libc_start_main (main=0x46ac3f <main>, argc=2, 
argv=0x7fffffffdc38, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdc28) at libc-start.c:287
#11 0x000000000057497e in _start ()
}}}

Original comment by robertm...@gmail.com on 9 Jul 2014 at 11:05

[GoogleCodeExporter]

Worth noting that the failure occurs on a column of type DECIMAL(18,0) which in 
the DataBase I'm using (EXASol) is the standard INT value, and that the problem 
can be worked around, in a very hacky way, by CASTing the result to a string:

SELECT CAST(<TROUBLESOME_COL_NAME> AS VARCHAR(20)) FROM <TABLENAME>;

Original comment by robertm...@gmail.com on 9 Jul 2014 at 1:53

[GoogleCodeExporter]

Feel like I'm flogging a dead horse here, but for any poor sod who's hitting 
the same issue as me, here's a tiny bit more information:

A minimum failing example is:

SELECT 1 UNION ALL SELECT NULL;

So it seems the problem is when there is a NULL in a DECIMAL() column. All this 
query does is create a resultset with a single column of type DECIMAL(), with a 
single NULL in it. When this resultset is parsed by pyodbc, it segfaults.

Original comment by robertm...@gmail.com on 28 Oct 2014 at 5:05