After installing unixODBC and the Netezza drivers on a Linux client and configuring ~/.odbcinst.ini and ~/.odbc.ini data sources according to the documentation, attempting to connect to a Netezza PureData warehouse via some tools may yield an error similar to:
(Error) ('HY000', '[HY000] [unixODBC]Error occurred while loading translation library (45) (SQLDriverConnect)')
For example, this was output by the Python SQLAlchemy library via a DBAPI connection on a RHEL7 box (though has been reported from other distributions and other tools).
Does anyone know the detail of what is happening and how to properly resolve it?
Extra info: I had a similar issue with the exact same error message.
Turns out I had /etc/odbcinst.ini set up with UnicodeTranslationOption=utf8 for the [NetezzaSQL] driver.
Also a wrong (32-bit) driver was used.
Fixed with /etc/odbcinst.ini:
[NetezzaSQL]
Driver = /opt/netezza/lib64/libnzodbc.so
DebugLogging = true
LogPath = /tmp
Trace = 0
TraceAutoStop = 0
TraceFile = /tmp/trace.log
UsageCount = 1
One way to work-around the issue, is to add the following lines to the specific data-source section of your ~/.odbc.ini file:
TranslationDLL=
TranslationName=
TranslationOption=
I don't know what other implications doing that may have (for example on non-English error messages or using unusual character encodings).
Set the UnicodeTranslationOption to be UTF16 instead of UTF8 in your odbc.ini. Make sure that it has that setting in both the odbc.ini recognized by 'odbcinst -j' and also a spare copy in your home directory called just 'odbc.ini'. The latest netezza files seems to read the configuration without being a hidden file '.odbc.ini'
You can also enable Netezza ODBC debug log to figure out detailed error. In odbcinst.ini , set
DebugLogging = true
Related
I need help with a task.
I have a VBA code at Excel to send some datas for PostgressSQL.
These days I reinstalled my Excel, but now, when I try to send the data the VBA presents the message below and the data is not include in my database:
"[ODBC driver manager] data source name not found and no default driver specified"
The debug highlight that the problem is in Conexao.Open. Below is part of the code with this:
Sub Conectar_BD()
Set Conexao = New ADODB.Connection
Conexao.ConnectionString = "DRIVER={PostgreSQL ANSI(x64)}; SERVER=localhost; DATABASE=yyyy; UID=marcel; PASSWORD=xxx;"
Conexao.Open
End Sub
Looking for some answers I found the explanation that I have to install the driver, but I´m not sure about how I could do that.
However, researching more I discovered a tutorial teaching how to connect the driver by admnistrative tool in the panel of control of windows called Datasource ODBC.
Following the instructions, when I added PostgreSQL ANSI(x64), that is there and put the credentials of my database, the conecction was sucessfully but the excel continue to present the same message.
Anyway, I don´t know how to fix this problem yet.
Anyone can help me?
enter image description hereWhy does the fuction Utf8Helper::setCollatorLanguage in arangodb sdk always return false?
It is at fault ERROR ERROR in the Collator: : createInstance < > : U_FILE_ACCESS_ERROR；And It's lead to failed to initialise ICU; ICU_DATA= "F:\\work_lc\\arangodb-2.6\\Build32\\bin\\..\\\\share\\arangodb\\";This project where to copy from others, it can be used, but i'm not,I just wonder what configuration file not produced
You need to make shure, ICU is able to load its locale database.
See our cookbook regarding windows compilation how to achieve this.
Please note that ArangoDB 2.6 is way out of date, and you should work with a more recent version.
More recent versions will also provide better error messages in such situations via the windows event log.
I have a question regarding the following warning when using
Ezjail-3.4.1 on FreeBSD 10.2
/etc/rc.d/jail: WARNING: Per-jail configuration via jail_* var "enter code here" iables is obsolete. Please consider to migrate to /etc/jail.conf "enter code here"It is my understanding that this has changed in FreeBSD 9.0 but since 10.2 the new way is the default method and that warning is being generated.I haven't been able to find any information about this on google, a lot of users mentioning the errors but ignoring them because their jails still work.AFAIK in 10.0 the rc.d/jail script converts the old-style jail_
variables into a temporary jail.conf to handle the jail. So the warning
is generated by rc.d/jail
Regards
Mr-Hill
As you found out, jails on FreeBSD 10.x use a new configuration method. From /usr/src/UPDATING:
20131010:
The rc.d/jail script has been updated to support jail(8)
configuration file. The "jail_<jname>_*" rc.conf(5) variables
for per-jail configuration are automatically converted to
/var/run/jail.<jname>.conf before the jail(8) utility is invoked.
This is transparently backward compatible. See below about some
incompatibilities and rc.conf(5) manual page for more details.
These variables are now deprecated in favor of jail(8) configuration
file. One can use "rc.d/jail config <jname>" command to generate
a jail(8) configuration file in /var/run/jail.<jname>.conf without
running the jail(8) utility. The default pathname of the
configuration file is /etc/jail.conf and can be specified by
using $jail_conf or $jail_<jname>_conf variables.
Please note that jail_devfs_ruleset accepts an integer at
this moment. Please consider to rewrite the ruleset name
with an integer.
ezjail was never updated to use this new method, but that's ok: FreeBSD still accepts the previous method. You can ignore this warning.
I am getting this error when entity framework trying to get schema from Informix database:
IBM.Data.DB2.DB2Exception (0x80004005): ERROR [IX000] [IBM][IDS/UNIX64] SQL0969N
There is no message text corresponding to SQL error "-23103" in the message fi
le on this workstation. The error was returned from module "IFX11500" with orig
inal tokens "". SQLSTATE=IX000
Please help.
Probably you have some LOCALE misconfiguration between the client and server or some problem with the client installation.
Try confirm the locale used at the database and set the CLIENT_LOCALE with compatible value.
-23103 Code-set conversion function failed due to an illegal sequence or invalid value.
Illegal or invalid characters occur in the character string. The
program could not execute the code-set conversion on the characters
that this string contains. Reexamine the input string for illegal or
invalid characters and reexecute the program.
If you have an alternative way to connect at the database , run this SQL :
select * from sysmaster:sysdbslocale
You will get a information like this..
dbs_dbsname sysmaster
dbs_collate en_US.819
dbs_dbsname sysha
dbs_collate en_US.819
dbs_dbsname sysuser
dbs_collate en_US.819
dbs_dbsname onpload
dbs_collate en_US.819
This links maybe can help you : dbaccess info , database locale
This problem temporarily solved by recycle the database service.
Still trying to find root cause of the problem as this may not be solution for every time.
Thanks
Phani
The above problem got solves after installing a patch. The problem is not exist in newer versions of Informix.
I tried to trace ODBC function calls from my program working on Linux. This program dynamically links ODBC manager and then connect to database and fetch some data.
I can trace ODBC calls with unixODBC by adding to odbcinst.ini:
[ODBC]
Trace=yes
TraceFile=/tmp/sql.log
This method is documented by IBM: Collecting data for an ODBC Problem
But when I change manager from unixODBC to Informix's own manager (libifdmr.so), the trace file is not created. Anybody successfully obtained ODBC trace from Informix manager (and driver) on Linux?
Client version: CSDK 3.50UC3
I hope that it is not a bug and something is wrong with my config.
As for unixODBC: I cannot use unixODBC in multithreaded app. I use connection pool and my app segfaulted when disconnection was from another thread than connection. It is also much slower in multithreaded app.
If you run:
strings $INFORMIXDIR/lib/cli/libifdmr.so | grep _OdbcSetTrace
do you get to see any references. If not, then the library is without the support functions. If you do see that, the mechanism outlined should work. If it doesn't, you probably have a reportable bug.
What level are you trying to trace the issues? And, since unixODBC works, why not use the driver manager that does work?
I've taken the example distsel.c from $INFORMIXDIR/demo/cli and compiled it on Solaris 10 using CSDK 3.50.FC3. I got it to the point where the connection succeeds, but the table 'item' is missing in the database I'm using, so the program stops SQLExecDirect(). When I run it under 'truss' (equivalent of 'strace' on Linux), then I see no evidence of the code even trying to open the trace file.
I compiled using:
gcc -I$INFORMIXDIR/incl/cli distsel.c -DNO_WIN32 \
-L$INFORMIXDIR/lib/cli -lifdmr -lifcli -o distsel
I used the following .odbc.ini file:
;
; odbc.ini
;
[ODBC Data Sources]
odbc_demo = IDS 11.50.FC3 stores on black
[ODBC]
Trace = yes
TraceFile = /tmp/odbc.trace
[odbc_demo]
Driver = /usr/informix/11.50.FC1/lib/cli/libifcli.so
Description = IBM Informix CLI 3.50
Server = black_19
FetchBufferSize = 99
UserName = jleffler
Password = XXXXXXXX
Database = stores
ServerOptions =
ConnectOptions =
Options =
ReadOnly = no
And this one:
;
; odbc.ini
;
[ODBC Data Sources]
odbc_demo = IDS 11.50.FC3 stores on black
[odbc_demo]
Driver = /usr/informix/11.50.FC1/lib/cli/libifcli.so
Description = IBM Informix CLI 3.50
Server = black_19
FetchBufferSize = 99
UserName = jleffler
Password = XXXXXXXX
Database = stores
ServerOptions =
ConnectOptions =
Options =
ReadOnly = no
Trace = yes
TraceFile = /tmp/odbc.trace
Consequently, I believe you have found a bug. I'm not sure whether the bug is in the FAQ you referenced or in the product - I'm inclined to think the latter. You should report the issue to IBM Technical Support. (I've not checked the Informix CLI (ODBC) manual; it might be worth checking that before trying to file a product bug; if the manual indicates that Trace doesn't work, and perhaps if it doesn't indicate that it does work, then there is a bug in the FAQ page you listed.)
If you are looking to see the SQL data, the SQLIDEBUG part of the FAQ works:
SQLIDEBUG=2:distsel ./distsel
That generated a file distsel_6004_0_102d40 for me - it will be different for you. You can then use the 'sqliprint' utility to see the data flowing between client and server.
If you cannot find 'sqliprint', get back to me.
I got ODBC trace with those settings in my odbc.ini:
[ODBC]
TRACE=1
TRACEFILE=/tmp/odbc_trace.txt
TRACEDLL=idmrs09a.so
I copied them from IBM Informix ODBC Driver Programmer’s Manual Version 3.50.
So other IBM documents seems not valid while those settings are in odbc.ini instead of odbcinst.ini and you must set TRACEDLL which was not mentioned in "Collecting data for an ODBC Problem" document.
UPDATE:
It seems IBM changed documentation: there is info on TRACEDLL, but odbcinst.ini remained.