Wednesday, April 22, 2009

Oracle form size-(Introduction of P-Code???)

Yesterday I was doing some maintenance on one form. So achieve desired functionality I modified it. I hardly added 4-6 procedures of average 8-10 line of codes. Initially forms .fmb size was about 3.4MB. After modification it become around 8.5MB. I was wondering what has happened with form…

One of my Team member suggest me to replace ‘;’ with ‘;’ in all code which is very common solution is something is not working as expected. I did so. But Due to that is it broken inheritance “Trigger Text” of inherited trigger at Form, Block and item level. Property classes trigger’s inheritance was also broken. So I have to re-inherit all the triggers manually. Finally form size was reduced to 3.2MB. That guy told me that “P-code” has been inserted into form. I googled for p-code related to Oracle forms but unfortunately i didn’t get any information.

So chaps do have any idea, thoughts on it. Please reply.

Wednesday, April 1, 2009

Do_key and Execute_trigger

EXECUTE_TRIGGER built-in
Description - EXECUTE_TRIGGER executes an indicated trigger.
Syntax
PROCEDURE EXECUTE_TRIGGER(trigger_name VARCHAR2);

Built-in Type -

restricted procedure (if the user-defined trigger calls any restricted built-in subprograms)
Enter Query Mode – yes

Note:

EXECUTE_TRIGGER is not the preferred method for executing a user-named trigger: writing a user-named subprogram is the preferred method.


Parameters -

Trigger_name Specifies the name of a valid user-named trigger.

Usage Notes

Because you cannot specify scope for this built-in, Form Builder always looks for the trigger starting at the lowest level, then working up.
To execute a built-in associated with a key, use the DO_KEY built-in instead of EXECUTE_TRIGGER.
For example, rather than:
Execute_Trigger ('KEY-NEXT-ITEM');
Use instead:
Do_Key('NEXT_ITEM');
EXECUTE_TRIGGER restrictions
       Although you can use EXECUTE_TRIGGER to execute a built-in trigger as well as a user-named trigger, this usage is not recommended, because the default fail behavior follows a different rule than when invoked automatically by Form Builder as part of default processing. For example, in default processing, if the When-Validate-Item trigger fails, it raises an exception and stops the processing of the form.
However, if the When-Validate-Item trigger fails when it is invoked by EXECUTE_TRIGGER, that failure does not stop the processing of the form, but only sets Form_Failure to FALSE on return from the EXECUTE_TRIGGER built-in.