Sunday, June 7, 2009

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

Java Web Start

Java Web Start provides a browser-independent architecture.. No dependency on Browser make or version for launching forms in EBS.  Java a...