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.
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?
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.
Is there any reason to not use JDBC ?
I could connect from SAP BO to Impala with 32 Bit Impala JDBC drivers
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!
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.
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?"
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.
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.
Can you tell me the steps you followed to make the ODBC connection from your BO server to impala.
We are struggling with it.
We are gettingt he following error.
[BO Server]$ isql -v <DSN NAME> <DatabseUID>
[S1000][unixODBC][Cloudera][ThriftExtension] (3) Error occurred while contacting server: EAGAIN (timed out). The connection has been configured to use a SASL mechanism for authentication. This error might be due to the server is not using SASL for authentication.
[ISQL]ERROR: Could not SQLConnect
We are using kerberos for hadoop authentication.