invalid password in a combination of oracle 10g and 11g products

When it is the second time you have a “HUH am I crazy or what?” moment when dealing with an environment with a oracle 10g product talking to an 11g product, and you’re really glad you finally remember the reason of the first ‘HUH’ time, it’s time to write it down.

In the latest situation we had an oracle 10g database and an oracle 10 application server with a webservice deployed on it using a data source pointing to that 10g DB. No problem in this configuration yet.
The 10g DB was then migrated to 11g without any problems and only step left was switching the data source on the AS.
We were notified that the password was uppercase now as 11g has case-sensitive passwords.

So we changed the connection string of the data source, entered the password uppercase and applied changes. Testing the connection we got a ‘invalid password’ error though.
Probably we made a typo, so we retype the password. Still the error and while getting a bit unsure of our own typing skills we make sure caps lock is off and retype. Still..
To be sure, we restart the container and then test. Still.. We start and stop the container but still.. Totally confused we go to pl/sql developer, double-check tnsnames and try to connect: no problems.

I remembered then a situation of a couple of months a go where I had been going bonkers over a database link I had to make from a 10g to 11g DB.
I kept entering an uppercase password in the ‘edit database link’ screen of pl/sql developer checking different stuff and kept getting an invalid password when testing the altered db link.
As it turned out pl/sql developer actually creates this statement

ALTER DATABASE LINK databaselinkto11g
CONNECT TO schema11g IDENTIFIED BY SCHEMA11G;

But because this was executed on a 10g database the password got saved in lower case, but obviously you can’t see or check that..
Manually altering with quotes around the password did the trick in this situation.

Following this reasoning I expected the 10g AS to also use the lower case version of my upper case entered password.
Lower casing the password of the user on the 11g DB indeed solved the problem.

 
 
 
(Getting the AS or webservice to actually go to the changed connection in the data source also gave unexpected problematic behavior but that’s a different story..)

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>