1. I am sorry, I didn't express well my question :) By saying apps users I wanted to say applicative users (like GL, AP or other specific users like xx...).
So, I think it's the same as apps, we should use FNDCPASS to change pwd.
2. I modified some user password to install a specific package. But When I heard that we shouldn't modify it, I made back the changes with the value they gave me (of course with "alter user" ! :( and I am not proud with this action I know ).
In the morning of the day after, I heard the coming story:
customers have got the following error message while using oracle EBS (looking for some bills):
and after analysis, there was a problem about some standard packages which were invalid with the following error message:
Invoice Validation did not process Invoice Id Due to Tax Error:140264, Line Number: ORA-04063: package body "APPS.FND_FLEX_EXT" has errors ORA-06508: PL/SQL: could not find program unit being called: "APPS.FND_FLEX_EXT"
To solve the problem, Invalid objects were compiled however some of them couldn't be compiled:
Explaination given to me when I came back to the office was:
changing that password is the root cause of this issue (because Oracle kept in the memory the wrong password and that made a conflict some where ...) and they added that to solve the problem they have only compiled packages, I don't know how and which ones ! For me it's strange. . I know that there is dependence between objects but what is the role of the password in this ?
The password change happened in the afternoon and customers problem happened in the morning.
I don't believe that. This is why I am asking you to help me understand this. Where can I find informations to understand what happened and to see what was wrong.
"Oracle kept in the memory the wrong password and that made a conflict some where" - > this is NOT TRUE.
The reason behind your errors should be something different.
Some patching actions, some manual "alter" statements can be a cause for this.
Check the invalid packages. Take one of them as an example. Check its dependencies(objects). Check that objects.. Check their last modification times (last ddl times)
Check audit record (if enabled)
I believe you can find the cause by following these kinds of approaches.
t0 - there was a code running with that db user.
t1 - the code goes into critical section (doing some apps level transaction -- not db level, but apps level)
t2 - the code start doing its work.
t3 - you change the password.
t4 - the code still in its apps level transaction, but it designed to continue it with a new session.
t5 - the code tries the get a new session with the db password (which is written in some file or in some other table in db)
t6 - the code could not get the new session and its apps level transaction breaks..
this apps level transaction can be a routine that alter objects, recompile them and so on...
So that may be a reason.. But even if it is so , I don't accept this explanation -> "Oracle kept in the memory the wrong password and that made a conflict some where "
This means caching and if they are talking about the Oracle Database (by saying Oracle), it is not true.
Tell them to give you the details about this expression.