Personally, I prefer to use proxy accounts in this sort of situation. SYSTEM@mydb> create user proxy identified by pr0xy; User created. SYSTEM@mydb> create user test identified by t3st; User created. SYSTEM@mydb> grant create session to test; Grant succeeded. SYSTEM@mydb> alter user test grant connect through proxy; User altered. SYSTEM@mydb> connect proxy[test]/pr0xy@mydb Connected. TEST@mydb> show user USER is "TEST" On Wed, Nov 19, 2008 at 12:22 PM, Jared Still <jkstill@xxxxxxxxx> wrote: > Here is something to check for when temporarily changing passwords. > > The account may be assigned to a profile that prevents the reuse of a > password, > and may also prevent the use of your temporary password if it doesn't > meet the criteria of the verify password function. > > Best to check beforehand and plan for it. > > There is a way to work around the profile problem. > > Create a new profile with no options, for temporary use only. > > I will call it empty_profile here. > > alter user dblink_owner identified by new_password profile empty_profile; > > Do the rest of the work as this user. > > Change the password back; > > alter user dblink_owner identified by old_password; > alter user dblink_owner profile <original_profile>; > > You best document it if you are routinely audited, as these changes > will appear in sys.user_history$, which a sharp auditor may know about. > > Jared > > -- "I'm too sexy for my code." - Awk Sed Fred.