frmcmp_batch userid=apps/apps module=$AU_TOP/forms/US/FORM_name.fmb output_file=$PRODUCT_TOP/forms/US/FORM_name.fmx
module_type=form compile_all=special
frmcmp_batch userid=apps/apps module=<Name_of_pll_file> output_file=<Name_of_plx_file>
module_type=library compile_all=special
Why compile forms with compile_all=special
compile_all=special was originally introduced as a workaround for a bug that was fixed some time ago.
The main reason it is still recommended for Oracle Applications is due to the way attached libraries are inherited from other attached libraries, and the difficulties in subsequently removing them if added by mistake.
For example, if a new library is attached to CUSTOM.pll, that library also becomes directly attached to every form or library that has CUSTOM.pll attached, once the higher level object has been re-compiled.
With compile_all=yes, the new library would end up attached to both the source and generated objects, and removing it would be extremely difficult: as well as removing it from CUSTOM.pll, you would have to remove it from every library or form that had CUSTOM.pll attached.
With compile_all=special, the source is not updated, and only the generated files (.plx and .fmx) have the new library attached.
In the case where someone has mistakenly attached a library to CUSTOM.pll, (for example when they do not follow Oracle customization standards, and attach an Applications product library), you simply need to delete it from CUSTOM.pll, regenerate all the forms and libraries, and it will be gone.
If you never customize, or if you follow the standards documented in the Oracle Applications Developer's Guide, the use of compile_all=yes should never cause this kind of problem, but Oracle still recommends that you use compile_all=special.
If you open and save a form or library in the builder, it will inherit any new library attachments from its sub-libraries in the same way as if it was generated with compile_all=yes.
module_type=form compile_all=special
frmcmp_batch userid=apps/apps module=<Name_of_pll_file> output_file=<Name_of_plx_file>
module_type=library compile_all=special
Why compile forms with compile_all=special
compile_all=special was originally introduced as a workaround for a bug that was fixed some time ago.
The main reason it is still recommended for Oracle Applications is due to the way attached libraries are inherited from other attached libraries, and the difficulties in subsequently removing them if added by mistake.
For example, if a new library is attached to CUSTOM.pll, that library also becomes directly attached to every form or library that has CUSTOM.pll attached, once the higher level object has been re-compiled.
With compile_all=yes, the new library would end up attached to both the source and generated objects, and removing it would be extremely difficult: as well as removing it from CUSTOM.pll, you would have to remove it from every library or form that had CUSTOM.pll attached.
With compile_all=special, the source is not updated, and only the generated files (.plx and .fmx) have the new library attached.
In the case where someone has mistakenly attached a library to CUSTOM.pll, (for example when they do not follow Oracle customization standards, and attach an Applications product library), you simply need to delete it from CUSTOM.pll, regenerate all the forms and libraries, and it will be gone.
If you never customize, or if you follow the standards documented in the Oracle Applications Developer's Guide, the use of compile_all=yes should never cause this kind of problem, but Oracle still recommends that you use compile_all=special.
If you open and save a form or library in the builder, it will inherit any new library attachments from its sub-libraries in the same way as if it was generated with compile_all=yes.
No comments:
Post a Comment