This content has been marked as final. Show 8 replies
Are you using 220.127.116.11 client? There's a known issue with using 18.104.22.168 client against a version less than 22.214.171.124, documented in the following note:1 person found this helpful
ORA-1017 Trying To Change Expired Password Through Programmatic Interface From 126.96.36.199 To Lower Database Version (Doc ID 1426233.1)
At this point it doesn't look like it will be fixed as this was required due to security fix.
Thanks Greg for the post. This is a bummer. If I were to install the 10g client on the server and for that manner on my machine, could I choose the client to use based upon the DB version I'm working with? I'm just trying to understand/visualize how that would work in Visual Studio.
The version of the client I'm running is (looking at the OracleDataAccess reference properties):
Runtime Version: v2.0.50727
Edited by: user1750438 on Apr 4, 2012 9:34 AM
Are you sure you're using 188.8.131.52 ODP.NET at runtime? The issue mentioned previously is specific to 184.108.40.206 client software, and 220.127.116.11 should be 18.104.22.168 client.
I just tested 22.214.171.124 client against 10204 db and had no issue changing the password. Using 126.96.36.199 does fail though.
With respect to your question about ODP version, you can control the version the application references easy enough in VS, but I don't know how you'd go about changing the reference at runtime after ODP is already loaded since you'd need a db connection to determine what version the db is.
You can control the version of ODP loaded prior to the app being invoked via an app.config file.
Hope it helps,
Thanks again Greg. It looks like the client I have installed on my machine might be different than what's installed on the server. I think I have the 32 bit client installed and I think the server might have the 64 bit client installed. I'll need to figure this out with the admin.
Hello, my admin ran tnsping on the server and it came back as 64-bit Windows Version 188.8.131.52.0. Is the 64-bit version in step with the 32-bit version other then the obvious differences?
To confirm the version of Oracle.DataAccess.dll that is actually loaded by the application, use a tool like Process Explorer at http://sysinternals.com to check the process at runtime.
I also have the problem described in 1426233.1. I have a Oracle 10G2 Oracle engine and want to use the 184.108.40.206 ODAC, but am unable to change password.
Will this issue be solved and corrected in a future ODAC?
Unfortunately it's not an ODAC issue but Oracle client 220.127.116.11.
So if the security defect (mentioned above) is fixed in a later patch bundle for 18.104.22.168 then this will also be available to be applied to an ODAC install.
Hope this helps.