topic Linux ODBC driver Unknown error in Data Engineering

Linux ODBC driver Unknown error

TomBrick — Sat, 25 Jan 2025 11:41:44 GMT

Hi,

I'm trying to debug an issue connecting to Azure Databricks from a CentOS 7 machine. Testing on my own machine only required unixODBC, the databricks-odbc driver and the connection string which all worked fine. When I test from the CentOS 7 machine, I get the following error:
Simba::ODBC::Connection::SQLDriverConnectW: [Simba][Hardy] (69) Unknown error occurred during test connection

The connection logs seem to suggest this is down to an issue setting the Thrift Session Tag(?). I cannot find any information on this, or the Unknown error. I have checked that the machine and connect with telnet and curl, the certs are fine, TLS connection looks ok etc. It's worth noting I have also tested this on a CentOS 7 VM on my local machine and it worked there too, so doesn't appear to be due to that.
It does still seem like a network issue I just can't figure out how, mostly because I don't know what "AddSessionTagHeader" is really doing.

Is there any documentation around this that might help that I've missed?

Simba::SparkODBC::SOSessionManager::GetSession: +++++ enter +++++
Simba::SparkODBC::SOSessionManager::GetSession: Setting SERVER_NAME and DBMS_VER in OpenSession getInfos field.
Simba::SparkODBC::SOSessionManager::GetSession: Getting new session handle.
Simba::SparkODBC::SOTCLIServiceThreadSafeClient::OpenSession: TOpenSessionReq
client_protocol = HIVE_CLI_SERVICE_PROTOCOL_V1
client_protocol_i64 = SPARK_CLI_SERVICE_PROTOCOL_V8
Simba::SparkODBC::SOTCLIServiceThreadSafeClient::OpenSession: Reinitialized cookies cache in connection settings.
Simba::SparkODBC::SOTCLIServiceThreadSafeClient::OpenSession: +++++ profile enter +++++
Simba::ThriftExtension::TESettings::AddSessionTagHeader: +++++ enter +++++
Simba::SparkODBC::SOTCLIServiceThreadSafeClient::OpenSession: +++++ profile leave +++++
Simba::SparkODBC::SOTCLIServiceClient::~SOTCLIServiceClient: +++++ enter +++++
Simba::SparkODBC::SOHiveCxnPool::ReleaseBackendCxn: +++++ enter +++++
Simba::SparkODBC::SOHiveCxnPool::ReleaseBackendCxn: Add HS2 connection back to pool.
Simba::SparkODBC::SOConnection::SetProperty: +++++ enter +++++
Simba::ODBC::Connection::SQLDriverConnectW: [Simba][Hardy] (69) Unknown error occurred during test connection.

Re: Linux ODBC driver Unknown error

Allia — Mon, 27 Jan 2025 07:06:08 GMT

@TomBrick Greetings! Are you trying to establish a connection from a VM on Azure? Can you add below logging and add the log file here.

On MacOS and Linux, the odbc.ini file will need to be used to set the logging parameters at the DSN level.

Linux: /opt/simba/spark/lib/64/

To set logging or any configuration at the driver level(would work across all the DSN/DSN-less connections that use the driver), create/edit the simba.sparkodbc.ini file and add the logging configurations under [Driver] section.

[Driver]

ErrorMessagesPath=/opt/simba/spark/ErrorMessages/

LogLevel=6

LogFileSize=2097152000

LogPath=/tmp/debug

Re: Linux ODBC driver Unknown error

TomBrick — Mon, 27 Jan 2025 21:19:02 GMT

Hi,

Thanks for the reply, yes its an Azure VM. Both log files attached.

Thanks

Re: Linux ODBC driver Unknown error

Allia — Wed, 29 Jan 2025 06:26:09 GMT

@TomBrick Can you use the latest ODBC driver. Below is the link to download it.

https://www.databricks.com/spark/odbc-drivers-download

Also, can you add the parameters below in the simba.sparkodbc.ini file? This will give you more information about the issue. Please check the driver connection logs after reproducing the issue.

AllowDetailedSSLErrorMessages=1

I see below in the logs which could be due to a variety of issues.

DriverOAuthSupport::OAuthConnection::ReadTokenRefreshSqlState: Connection error SQLState is defaulting to SQLSTATE_CONN_FAILURE (08006)

For further troubleshooting, you may log a support case with us.

Re: Linux ODBC driver Unknown error

TomBrick — Sun, 02 Feb 2025 14:54:22 GMT

Reinstalled the latest driver and enabled DetailedSSLErrorMessages. Not reallly seeing much else in the logs.

I'll see about raising a support case.

Thank you for the help @Allia