| Issue 125: | Not returning all data | |
| 2 people starred this issue and may be notified of changes. | Back to list |
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.
Jan 7, 2014
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
Jan 7, 2014
It looks I'm using iodbc 3.52.6 instead of unixodbc.
Jan 7, 2014
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)
Jan 7, 2014
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)
Jan 7, 2014
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.
Jan 8, 2014
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.
Mar 6, 2014
Fixed with: https://github.com/mkleehammer/pyodbc/pull/23 |
Labels: OpSys-OSX