You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the Amazon Athena connector, the DSN call often fails with the following error:
Base.CodePointError{UInt32}(0x6f75712e)
Stacktrace:
[1] code_point_err(::UInt32) at ./char.jl:86
[2] Type at ./char.jl:160 [inlined]
[3] transcode(::Type{UInt8}, ::Array{UInt32,1}) at ./c.jl:286
[4] ODBCDriverConnect!(::Ptr{Nothing}, ::String, ::Bool) at /Users/aaron/.julia/packages/ODBC/P6nfr/src/ODBC.jl:29
[5] #DSN#3(::Bool, ::Type, ::String, ::String, ::String) at /Users/aaron/.julia/packages/ODBC/P6nfr/src/ODBC.jl:128
[6] Type at ./none:0 [inlined] (repeats 2 times)
[7] top-level scope at In[69]:1
The particular address differs each time. Sometimes, the call completes successfully.
I am not sure if this is related to my PWD (AWS_SECRET_ACCESS_KEY), which includes slashes.
The text was updated successfully, but these errors were encountered:
It would be worth checking if you still get errors on master (] add ODBC#master), since the big rewrite was merged. A CodePointError like this suggests some kind of unicode issue; iODBC by default uses UTF32, while unixODBC uses UTF16. It looks like the athena ODBC driver supports both iODBC and unixODBC, so it might be worth trying one or the other, on master, you can do ODBC.setunixODBC() or ODBC.setiODBC()); note that you can pass environment variables to be set when switching driver managers too; so if you wanted to set ODBCINI to your athena odbc.ini file location, you could do that.
Anyway, let me know if you're still able to reproduce and I can help try to diagnose further.
I think this is probably solved on master; there's been several updates/fixes with connection management, so I'm going to close and we can reopen if people see issues.
When using the Amazon Athena connector, the DSN call often fails with the following error:
The particular address differs each time. Sometimes, the call completes successfully.
I am not sure if this is related to my PWD (AWS_SECRET_ACCESS_KEY), which includes slashes.
The text was updated successfully, but these errors were encountered: