Created on 10-16-2015 02:29 AM - edited 09-16-2022 02:44 AM
We have connected Impala to SAP BusinessObjects, using the latest ODBC drivers available for Red Hat. We are running in to errors when we try to retrieve more than a very small amount of data. We can get perhaps up to about 50Kb either by applying LIMIT=<small number> or being very restrictive in the where clause. For example, on an Id column which starts at 1 and counts upwards we can get just over 8000 rows. Folks using non-Business Objects methods to access the data have no problem.
This has been raised with SAP but I'd be interested to see if this rings any bells with anyone.
Created 11-16-2015 12:38 AM
I can't begin to explain why, but we switched our database account to one with more access...and hey presto it all just works.
Created 10-16-2015 02:14 PM
Hi Nick,
I have not seen this issue myself but quite curious about it.
What kind of errors are you seeing?
The latest Imala ODBC driver available from the website is 2.5.29. I this the version you are using?
Thanks,
Holman
Created 10-19-2015 03:46 AM
Hi, thanks for your reply. Yes 2.5.29.
The error is "Your session timed out. Close the Java interface and log on again"
This is slightly misleading as if you limit the number of rows to 8191 or less it will run successfully. So an 8k row limit? Wondering if it relates to the UTF-8 / UTF-16 / UTF-32 settings in cloudera_impalaodbc.ini and odbc.ini....we just tested changes but they were sabotaged by some empty tables.
Created on 10-20-2015 09:29 AM - edited 10-20-2015 09:30 AM
Hello
Is there any reason to not use JDBC ?
I could connect from SAP BO to Impala with 32 Bit Impala JDBC drivers
Thanks
Created on 10-20-2015 11:21 PM - edited 10-20-2015 11:22 PM
Hi, the reason we aren't using JDBC.....is it doesn't work either! It works for us locally, but when we try server-side the error is "Fail to create an instance of Job : com/cloudera/impala/jdbc41/Driver : Unsupported major.minor version 51.0"
We understand this to mean work with Java 7 not 6....so our admin has made the appropriate change but it made no difference.
So, ODBC because we have got further than we have with JDBC!
Created 03-07-2017 05:00 AM
Hello,
What type of configuration needs to be made connect to impala using JDBC from IDT/ BO server.
Your help is greatly appreciated.
We are stuck at this point.
Thanks
Sandhya
Created 10-26-2015 12:55 PM
I asked around, and somebody knew somebody who asked Simba. They said:
"There shouldn't be a limitation on the number of rows imposed by the driver,
although there is a statement attribute for limiting the number of rows to return (SQL_ATTR_MAX_ROWS).
If there are further issues, can you please tell the customer to enable logging through
ODBC Administrator and send a zip file of the captured driver logs?"
Created 10-28-2015 12:21 AM
I appreciate you asking and passing the information on.
I will look to see how we can set SQL_ATTR_MAX_ROWS attribute and enable logging. If anything is output I'll see if it can be attached here. Thanks again.
Created 10-30-2015 04:17 AM
We can't set SQL_ATTR_MAX_ROWS via Business Objects. We've now generated the log file - I don't see a way to attach it here. The only error is as follows:
Oct 30 11:06:42 INFO 392800576 Connection::SQLSetConnectAttr: Attribute: Unknown Attribute (11003) Oct 30 11:06:42 INFO 392800576 ConnectionAttributes::SetAttribute: Invalid attribute: 11003 Oct 30 11:06:42 ERROR 392800576 Connection::SQLSetConnectAttr: [Cloudera][ODBC] (10210) Attribute identifier invalid or not supported: 11003 Oct 30 11:06:42 INFO 392800576 Statement::SQLColAttributeW: FieldIdentifier: SQL_DESC_TYPE_NAME (14) Oct 30 11:06:42 INFO 392800576 Statement::SQLColAttributeW: FieldIdentifier: SQL_DESC_UNSIGNED (8) Oct 30 11:06:42 INFO 392800576 Statement::SQLSetStmtAttrW: Attribute: SQL_ATTR_ROW_ARRAY_SIZE (27)
However, this exact same error is thrown regardless of whether or not the problem occurs. It isn't clear - to me at least - what this invalid attribute actually is.
I can post the full 300 lines from the log file but assume no one want to wade through that. We used loglevel=5 so all we miss are TRACE statements.
Created 11-16-2015 12:38 AM
I can't begin to explain why, but we switched our database account to one with more access...and hey presto it all just works.