Introduction
We use Informia Archive software to archive historical financial data from the E-Business Suite. For reporting purposes, we have created a couple of custom responsibilities in the E-Business Suite so that users can run concurrent requests. All forms associated with these custom responsibilities started displaying the APP-FND-01508: Failed to Connect error. An event trace for the ORA-01017 error (invalid username/password) showed a custom database user 'amarchive' in the trace file whenever the above connect error was displayed. Upon further investigation, i found that the password of this custom database user was changed with the 'alter user amarchive identified by newpass' command. In normal circumstances, such a command would seem the right way to change the password of a custom database schema user. However, it was not the case in our database. The custom user was registered as an Oracle Applications module and hence it has an entry in the fnd_oracle_userid view. An alter user command only updates the password in the dba_users view and hence the password in fnd_oracle_userid does not get changed. A successful forms connection process needs both fnd_oracle_userid and dba_users view contain the same password. This can be accomplished only by using the FNDCPASS command.
The other day i spent almost two hours to know the source of a APP-FND-01508: Failed to Connect error occurring in all forms associated with some custom responsibilities in the Applications 11i E-Business Suite. The problem started after changing the password of a custom database user 'amarchive' that is used to connect to open the forms from the applications' responsibility navigation pane.
Problem
We use Informia Archive software to archive historical financial data from the E-Business Suite. For reporting purposes, we have created a couple of custom responsibilities in the E-Business Suite so that users can run concurrent requests. All forms associated with these custom responsibilities started displaying the APP-FND-01508: Failed to Connect error. An event trace for the ORA-01017 error (invalid username/password) showed a custom database user 'amarchive' in the trace file whenever the above connect error was displayed. Upon further investigation, i found that the password of this custom database user was changed with the 'alter user amarchive identified by newpass' command. In normal circumstances, such a command would seem the right way to change the password of a custom database schema user. However, it was not the case in our database. The custom user was registered as an Oracle Applications module and hence it has an entry in the fnd_oracle_userid view. An alter user command only updates the password in the dba_users view and hence the password in fnd_oracle_userid does not get changed. A successful forms connection process needs both fnd_oracle_userid and dba_users view contain the same password. This can be accomplished only by using the FNDCPASS command.
FNDCPASS apps/**** 0 Y system/***** ORACLE AMARCHIVE newpass
Solution
I used the FNDCPASS command to change the password again (used the same password specified in the alter user command) and this command synchronized both fnd_oracle_userid and dba_users views, enabling successful forms navigation again.
Conclusion
Conclusion
Many Oracle E-Business Suite 11i databases have custom database schema users. These schema users have to be verified whether they are registered as application modules. If yes, then the users have entries in the fnd_oracle_userid view also. The only way to change password for registered application modules is through the FNDCPASS command.
