My continuous expedition and dissemination of knowledge and experience about Oracle, now found recognition for the 7th time, as an Oracle Ace Pro.
My kindest gratitude's to Oracle and to Ace Community.
-------------- "Erman Arslan's Oracle Forum is available now. Click here to ask a question. " --------------
My continuous expedition and dissemination of knowledge and experience about Oracle, now found recognition for the 7th time, as an Oracle Ace Pro.
My kindest gratitude's to Oracle and to Ace Community.
Things are a little slow in the summer months, but we continue to answer questions as intensely as possible.
Remember, you can ask questions and get remote support using my forum. Just click on the link named "Erman Arslan's Oracle Forum is available now". Click here to ask a question", which is available on the main page of Erman Arslan's Oracle Blog. More than 2000 questions were asked, almost 10000 comments have been made and here is the links to the latest questions from the last period.
Today's issue is from Oracle EBS domain. I will be fast and clean and give you the error, the cause and the solution without dancing around the subject. Okay... Let's go!
->
PROBLEM:
While performing ADOP cleanup phase, we failed with the AutoPatch error seen below..
AutoPatch error:
Unable to get APPS_DDL package version from db <XX_CUSTOM_SCHEMA> <APPS_DDL> <PACKAGE>
AutoPatch error:
adpmrp: Error while installing apps_ddl packages.
It was due to an EBS-side config of a custom schema and the the cause of the issue could be identified using the query below;
select ORACLE_USERNAME, READ_ONLY_FLAG, ENABLED_FLAG, ORACLE_ID, INSTALL_GROUP_NUM, last_update_date from FND_ORACLE_USERID where ORACLE_USERNAME in ('XX_CUSTOM_SCHEMA');
--ENABLED_FLAG and READ_ONLY_FLAG were suspicious, and in our case the problem was related with the value of the READ_ONLY_FLAG.
SOLUTION:
*Connect to the database using sqlplus and APPS user
*Take a back up of the table fnd_oracle_userid
create table fnd_oracle_userid_bkp2 as select * from fnd_oracle_userid;
*Check the values before changing for reference.
select ORACLE_USERNAME, READ_ONLY_FLAG, ENABLED_FLAG, ORACLE_ID, last_update_date from FND_ORACLE_USERID where ORACLE_USERNAME in ('XX_CUSTOM_SCHEMA');
*Use the following update, and fix the issue.
update fnd_oracle_userid set read_only_flag='A' where ORACLE_username in ('XX_CUSTOM_SCHEMA');
commit;
--In our case READ_ONLY_FLAG was set to U, and that was causing the issue.
Note the description of the values of READ_ONLY_FLAG column;
C - Category 5 - APPLSYSPUB*Check if the values are corrected as expected.
select ORACLE_USERNAME, READ_ONLY_FLAG, ENABLED_FLAG, ORACLE_ID, last_update_date from FND_ORACLE_USERID where ORACLE_USERNAME in ('XENP');
Re-run adop cleanup phase, and you will see the issue will be disappeared.
adop phase=cleanup