Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
User experienced ODBC connection failures on a new Informix 11.70 instance on AIX, with password validation errors despite successful local dbaccess connections. Suggested fixes included adjusting NS_CACHE configuration parameter (to user=0 or NS_CACHE=0) and verifying user permissions, but no clear resolution was reported in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
Good Day to everyone let me first give you an idea on our environment before
proceeding with the question. We have an informix (11.70 FC7) Production
server running in AIX 6.1 which have 3 instances running. We recently add
another instance which will cater a new built application, all local
connections are working flawlessly as well as tuxedo connections. I already
added the DBA priv to the instance user and we can access the database via
dbaccess.
The problem was when we created an odbc connection to the server which
resulted to below errors appearing on the online log of the instance.
18:57:47 Password Validation for user [user] failed!
18:57:47 Check for password aging/account lock-out.
18:57:47 listener-thread: err = -952: oserr = 0: errstr =
user@::ffff:10.1.1.1: User (user@::ffff:10.1.1.1)'s password is not correct
for the database server.
We tried resetting the id's password, tried connecting via putty (which
works), restart service, add CONNECT/DBA priv to the user,try the informix
user but the odbc kept on failing (this only happens on the new instance, the
other 3 instances all have successful odbc connections). Maybe there is
someone in here that already encountered and solve this kind of problem.
Appreciate all the help thanks in advance...
Hi Lester,
What is the value of NS_CACHE configuration parameter?
You can try to change it's value to:
NS_CACHE=host=900,service=900,user=0,group=900 and restart the instance.
You can try even with NS_CACHE=0.
Don't forget to restart the Informix instance. If you try to change the value
of NS_CACHE with "onmode -wm/wf" there is a bug in 12.10 and I'm not sure for
11.70.
Regards,
Hi BOYCHO,
Thanks for the reply below are the parameters or NS_CACHE in our instance
NS_CACHE host=900,service=900,user=900,group=900
I tried doing what you said (changing user = 0 and even the NS_CACHE = 0 then
restart instance) to no avail. I still received the same error message =(
Hi Lester,
Our client a year ago had the same problem with 11.70.FC4 on AIX. They also
like you had no problems with password using dbaccess through PUTTY. They had
problem with ODBC connections.
After changing the parameter NS_CACHE host=900,service=900,user=0,group=0 ,
the problem with password on the "fat client" (for example ODBC) disappears.
May be your case is a different one.
Regards,
Hi Lester,
The answer is NO. If you try just comment out the NS_CACHE parameter, you will
receive default value for NS_CACHE - host=900,service=900,user=900,group=900.
If you want to disable NS_CACHE just put "NS_CACHE 0" in configuration file
and restart instance and the client. But you told me that already test this
without success.
Try again with dbaccess, but with dbaccess -> Connection -> Connect -> User ->
Password, to be absolutely sure, that there is no problem with name and
password of the user.
Also check the installation of this instance - permissions, rights of the
binaries and so on.
May be the problem is with password and shadow files, but it's strange that
all others instances work without problems through ODBC with this user.
You can try to find more information for analogical problems here:
http://www-01.ibm.com/support/docview.wss?uid=swg21607817
That is all that I can do. Sorry if I could not help you.
Best regards.
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.