• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 14 subscribers
  • Views 7551 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to migrate a Profile designated with a Responsibility?

dianne.jones
over 6 years ago

I simply need to Migrate a Profile that is designated at a Responsibility level.   I can archive and migrate the Responsibility.  However, the Profile settings for the given Responsibility cannot be archived - which means it cannot be migrated?   I check the Extended Objects - and apparently it is not available there either?  Am I looking at the wrong place?  If not - and STAT cannot handle this - any suggestions for an alternative solution?

  • 0 over 6 years ago
    Hi Dianne,

    We found a solution using Oracle's FNDLOAD command, and created our own Stat Custom Object. This solution comes with the same problems as other FNDLOAD solutions. Because the Oracle LCT file uses keys based on primary key values, you can have problems when the key values on the target already exist and have a different value then the source.

    Let me know if you are interested and I will export from Stat and attach to the forum.

    Regards.
    Tom Shaw
  • 0 over 6 years ago
    We did likewise :) I always say to our dev team, if you can do it in FNDLOAD, then I can create an object to do it in Stat. I've always thought it would be good if Stat could treat FNDLOAD setup objects as file objects, since we could hack an LDT file to be uploaded.

    Thanks,
    Nic
  • 0 over 6 years ago
    Thank you ! Yes - I was developing a solution utilizing a kornshell script to execute the Download and by assigning a STAT custom file object of lct - we could archive and migrate the file. However, I then tripped across an Oracle API (fnd_profile.save) executed via SQL. We can simply execute via SQL and input the required values (Profile_name, profile_option_value, 'RESP', responsibility_id, application_id). Not necessarily fool-proof due to the ability to provide typos; however if you test by migrating to an environment before the production migration - you have an opportunity for corrections.
    Thank you for your responses !