My favorites | Sign in
Project Home Downloads Wiki
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 125: Not returning all data
2 people starred this issue and may be notified of changes. Back to list
Status:  Investigating
Owner:  ----


 
Reported by tyl...@gmail.com, Oct 8, 2010
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.


Nov 21, 2010
Project Member #1 mkleehammer
This seems strange.  Can you provide an ODBC trace for this?

Status: Investigating
Labels: OpSys-OSX
Jan 7, 2014
#2 zroadho...@rmn.com
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
#3 zroadho...@rmn.com
It looks I'm using iodbc 3.52.6 instead of unixodbc.
Jan 7, 2014
#4 zroadho...@rmn.com
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
#5 zroadho...@rmn.com
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
#6 zroadho...@rmn.com
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
#7 zroadho...@rmn.com
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.

Powered by Google Project Hosting