Why personalization?
- Oracle Supports personalization unlike customization
- Personalization are stored in tables rather than files
- Will not have a bigger impact when you upgrade or apply patches to the environment
- Can be moved easily through FNDLOAD from one instance to other
- Can be restricted at site/responsibility/user level
- Easy to disable/enable with click of a button.
- Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
- Can be applied to new responsibilities/users easily.
- Can be restricted to function or form.
- Zoom from one form to another
- Pass data from one form to another through global variables
- Change LOV values dynamically
- Enable/Disable/Hide fields dynamically
- Display user friendly messages when required
- Launch URL directly from oracle form
- Execute PL/SQL programs through FORM_DDL package
- Call custom libraries dynamically
- Adding a new screen/tab/form/column in an existing Oracle Application form. This has to be done through development tool such as Forms. However, this approach is not advised. If you must add a form, it can be developed and a Zoom into this if needed can be invoked in the Oracle Application's existing menu form/function.
- Altering the look and feel of an existing Oracle Screens completely different from the original. For example, instead of the block being in the first tab, the block cannot be moved to the next tab. However, sequence of tab function like the next navigation block can be controlled.
- Adding a button in the existing form where the button has never existed. However, an existing button can be disabled or can be made invisible.
- There cannot be more than 100 sequence in the Form Personalization. An error of FRM-40207: Must be in the range 1 to 100 will be displayed. However, there can be duplicate sequences.
- No COMMIT triggers/event can be used (KEY-COMMIT, PRE-COMMIT, ON-COMMIT). If requirement ask to prevent saving of a record given a particular condition the WHEN-VALIDATE-RECORD event can be used instead. The negative about this trigger event is that a save event cannot be distinguished from the validation that is happening if user go to the next record or block where the form will be automatically gets validated before saving it. The act of saving and validation are treated the same in this trigger. If there is one that can identify one from the other, let me know and this blog needs updating.
Comments
Post a Comment