search

Bobspadger / pyodbc

Automatically exported from code.google.com/p/pyodbc
MIT No Attribution
0 stars 0 forks source link

Not returning all data #125

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
(This is connected to a Intersystems Cache' database

select count(*) from coredata; = 44618 rows
select * from coredata,.fetchall or iterate = 39 rows
select * from coredata order by primary_key desc, = 0 rows

Clearly there is something in the data causing an issue. I've pulled 50k+ rows 
from another table with no problem.

The table is fairly large, 48 columns in all, most interger, some double, some 
varchar(255), and 3 longvarbinary and 1 longvarchar.

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

I expect select * to return the same number of rows as a count query.

What version of the product are you using? On what operating system?
2.1.8, on Mac OS X 10.5 PPC

Please provide any additional information below.

Original issue reported on code.google.com by tyl...@gmail.com on 8 Oct 2010 at 7:46

GoogleCodeExporter commented 9 years ago 
This seems strange.  Can you provide an ODBC trace for this?

Original comment by mkleehammer on 21 Nov 2010 at 5:22

GoogleCodeExporter commented 9 years ago 
I'm running into this same issue when querying a Vertica database using pyodbc. 
 It seems like when pyodbc gets to a row with a long column value, it silently 
stops.

OSX 10.7.5 x86_64
Python 2.7.5
pyodbc 3.0.6
unixODBC 2.3.1

Original comment by zroadho...@rmn.com on 7 Jan 2014 at 8:08

GoogleCodeExporter commented 9 years ago 
It looks I'm using iodbc 3.52.6 instead of unixodbc.

Original comment by zroadho...@rmn.com on 7 Jan 2014 at 8:36

GoogleCodeExporter commented 9 years ago 
I turned on odbc tracing and see the following:

[000001.769150]
python          7FFF71625960 ENTER SQLGetData
        SQLHSTMT          0x7fa06c2ea840
        SQLUSMALLINT      2
        SQLSMALLINT       1 (SQL_C_CHAR)
        SQLPOINTER        0x7fff6b96ebd0
        SQLLEN            1024
        SQLLEN          * 0x7fff6b96eb90

[000001.769291]
python          7FFF71625960 EXIT  SQLGetData with return code 1 
(SQL_SUCCESS_WITH_INFO)
        SQLHSTMT          0x7fa06c2ea840
        SQLUSMALLINT      2
        SQLSMALLINT       1 (SQL_C_CHAR)
        SQLPOINTER        0x7fff6b96ebd0
        SQLLEN            1024
        SQLLEN          * 0x7fff6b96eb90 (-4)

Original comment by zroadho...@rmn.com on 7 Jan 2014 at 8:52

GoogleCodeExporter commented 9 years ago 
This is the trace of the describe column for the problematic column:

[000001.768903]
python          7FFF71625960 ENTER SQLDescribeCol
        SQLHSTMT          0x7fa06c2ea840
        SQLUSMALLINT      2
        SQLCHAR         * 0x7fff6b96f0a0
        SQLSMALLINT       300
        SQLSMALLINT     * 0x0
        SQLSMALLINT     * 0x7fff6b96f09e
        SQLULEN         * 0x7fff6b96f090
        SQLSMALLINT     * 0x7fff6b96f08e
        SQLSMALLINT     * 0x7fff6b96f08c

[000001.768931]
python          7FFF71625960 EXIT  SQLDescribeCol with return code 0 
(SQL_SUCCESS)
        SQLHSTMT          0x7fa06c2ea840
        SQLUSMALLINT      2
        SQLCHAR         * 0x7fff6b96f0a0
                  | products                                 |
        SQLSMALLINT       300
        SQLSMALLINT     * 0x0
        SQLSMALLINT     * 0x7fff6b96f09e (SQL_VARCHAR)
        SQLULEN         * 0x7fff6b96f090 (65000)
        SQLSMALLINT     * 0x7fff6b96f08e (0)
        SQLSMALLINT     * 0x7fff6b96f08c (SQL_NULLABLE)

Original comment by zroadho...@rmn.com on 7 Jan 2014 at 8:54

GoogleCodeExporter commented 9 years ago 
I was able to reproduce this issue using isql on our production boxes - the 
problem may be with the Vertica ODBC driver we are using.

Original comment by zroadho...@rmn.com on 7 Jan 2014 at 9:56

GoogleCodeExporter commented 9 years ago 
After more investigation, it does look like the problem is in pyodbc.  We were 
able to successfully execute our query using both ruby/ruby-odbc and mxODBC in 
Python.  We'll add some tracing to getdata.cpp -> GetDataString as it looks 
suspect.

Original comment by zroadho...@rmn.com on 8 Jan 2014 at 6:26

GoogleCodeExporter commented 9 years ago 
Fixed with: https://github.com/mkleehammer/pyodbc/pull/23

Original comment by amacei...@rmn.com on 6 Mar 2014 at 5:35