I am writing a web based application that runs off an Oracle backend.
The database connection is established dynamically with the end-user supplying the login and password used for the jdbc connection from DriverManager. It looks something like this
(Assume variables are set somewhere else in the app)
DriverManager.getConnection(database, user, pass);
The entire process is completely generic, with the application using the user's DB access to create the connection.
The problem I have is that the passwords expire after 30 days. My requirement is that the application must provide a prompt for the user to change their password if it has expired.
The exact error is this -
java.sql.SQLException: [Oracle][ODBC][Ora]ORA-28001: the password has expired
I plan on catching this, I just don't know what to do after I've caught it.
Is there a way to change the connection password from JDBC if it is expired?
It's getting serious now folks.
There is an ASP.NET solution for this through Oracle's ODP.NET
Surely there must be a Java-based solution to this.
I have the go ahead from the company to just write this in ASP.NET, but I'd rather keep everything in one language and on one server. We're not allowed to run J2EE apps on Windows systems here.
First off, I'm answering this in haste, so let me give the disclaimer that I haven't tried any of this...
I'm not sure that you'll be able to use a pure-Java solution to this problem. But, I have seen this problem solved before using stored procedures. Basically, you set up a stored procedure in Oracle that changes the password (consult a DBA or someone more familiar with PL/SQL than I to help you out) and then call that using JDBC.
The one question I have is this: After you catch the exception telling you that the password is expired, do you even have a JDBC connection? My guess is that you don't have a connection, so there's not much you can do directly. What you'll probably have to do is catch that exception and then your app will have to log in to the database using a username with DBA access (i.e., enough rights to change someone else's password) and then call the stored procedure.
Again...this is all a theory, as I haven't tried it out yet.