A schema's password was changed in the database. The password is then updated in Toad's connection window. This works fine and the user can connect. However, if Toad is closed and re-opened, the old password reappears. The new password is no longer saved in the connection. It has reverted back to the password that was there prior to updating it in the connection window. This leads to an error saying that the username or password is not correct.
The way Toad works is that, when it is launched, it reads all the settings and connection information from the User Files folder. When it is closed, it writes all the settings and connection information back to the User Files folder. What is happening is an automated job is started, which launches Toad, and all the connection information is being read from the files at that time. While the automated job is running, Toad is launched by the user and the password is updated in the connection window. When this instance of Toad is closed, it writes the new password to the User Files folder. Before Toad is launched again, the automated job finishes and writes back the connection information it had read originally, which was the old password. This then overwrites the new password with the old password. When the user launches Toad again, it reads the old password from the files and it appears that Toad is not saving the changes that were made last time it was opened.
If there are automated jobs that are run by this installation of Toad for Oracle all throughout the day, there may always be an automated job running that has the old password saved to it. Those automated jobs may be contently writing back the old password, so it appears the new updated password is never changed.
If there are enough automated jobs constantly running, the Date Modified value for the connection files (connections.ini, connectionpwds.ini) can be seen up being updated in the User Files folder.
