Error: Obtaining diagnostic record from unixODBC handle failed

[econkc]

Hi,

I am trying to import big table from Teradata. It works perfectly but today I have come across an issue pulling the exact same table that I used to be able to pull before. The error is "Error: Obtaining diagnostic record from unixODBC handle failed". I am not sure if this is because the speed of the internet or else. I would be highly appreciated if somebody could shed me some light on how to fix this issue.

options = turbodbc.make_options(large_decimals_as_64_bit_types=True, use_async_io=True)

connection = turbodbc.connect(dsn='DSN', username='USER', password='PWD', turbodbc_options=options)

cursor = connection.cursor()

cursor.execute('SELECT * FROM TABLE')

df_n = cursor.fetchallnumpy()

cursor.close()

[xhochy]

The error is thrown here: https://github.com/blue-yonder/turbodbc/blob/master/cpp/cpp_odbc/Library/src/level2/level1_connector.cpp#L84-L88

We probably should include the native error message to reveal more details about what went wrong.

[dirkjonker]

It is not clear what the actual error is, as Turbodbc is not telling you the true reason the command failed. It tries to get more information on the failure, but it fails to do so. Instead you get this unfortunate error message that won't help you much in solving the problem.

You can try turning on the unixODBC trace functionality (see for example https://www.easysoft.com/support/kb/kb00945.html) which should record the native error message. This will have a severe performance impact so it may not be very useful. It may also write a very large log to disk, so please take this into account.

[krisevans]

We are also seeing this error occur intermittently. It may be happening when connectivity is lost to our cloud database but it is obviously not possible to tell without the native error message.

[pacman82]

Hello,

I do not know if this is the issue you are facing, but I can spot one bug within this code. There is no such thing as a maximum message size for diagnostics in ODBC. At the very least the code should also check for SQL_SUCCESS_WITH_INFO to detect truncation of the message and either fetch the entire message with a buffer large enough, or present the user with the truncated message.

Here is a piece of Rust code doing the same thing as the c++ code @xhochy shared: https://github.com/pacman82/odbc-api/blob/5a47b47a6321bd0a2c5e655211ad37e7fe37294a/odbc-api/src/handles/diagnostics.rs#L110

You can verify this hypothesis by testing your SQL Query with either the odbcsv or odbc2parquet tool. If they display the entire native error (and the message is long) then the issue is about the max size.

Cheers, Markus