Migrating Oracle 6i forms to 10g??

If you are migrating Oracle 6i forms to 10g then have a look at OTN discussion Tread.

KEY-DUPREC Trigger

Key-DupRec trigger is used to Copy previous record to current record in Create Record Mode. Whole record contains from last record including Sequence numbers are copied and newly record is not marked for validation. Item level validations are fired unless we go to item of newly created record and try to change it. If you are using PRE-INSERT trigger to generate Record last Change Details, auditing and Sequence number then duplicated records will have values calculated/generated in PRE-INSERT trigger.

Its is always better idea to code constraints to database side. If you code constraints at database end then

1) Constraint violating record never will be in database.

2) If your application have different middle tier and client tier implemented in different technologies/channels then you can just catch these ora errors and make them user friendly before displaying.

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.

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.

LIST_VALUES

LIST_VALUES displays the list of values for the current item, as long as the input focus is in a text item that has an attached LOV. The list of values remains displayed until the operator dismisses the LOV or selects a value. By default, LIST_VALUES uses the NO_RESTRICT parameter. This parameter causes Oracle Forms not to use the automatic search and complete feature. If you use the RESTRICT parameter, Oracle Forms uses the automatic search and complete feature. 

Automatic Search and Complete Feature: 

With the automatic search and complete feature, an LOV evaluates a text item's current value as a search value. That is, if an operator presses [List] in a text item that has an LOV, Oracle Forms checks to see if the item contains a value. If the text item contains a value, Oracle Forms automatically uses that value as if the operator had entered the value into the LOV's search field and pressed [List] to narrow the list. If the item value would narrow the list to only one value, Oracle Forms does not display the LOV, but automatically reads the correct value into the field.

Usages of RESTRICT  kwyword:

Where list value has too many valus then it affects the performance of the application. At that time use RESTRICT.

Oracle Forms-DEFAULT_VALUE Built-in

DEFAULT_VALUE built-in in oracle forms is used for assign value to variable if value of variable is NULL.
IF :DBT_BRANCH.LOCATION IS NULL THEN
:DBT_BRANCH.LOCATION:='Pune';
END IF;
is equivalent to
default_value('Pune','DBT_BRANCH.LOCATION');
But DEFAULT_VALUE is noramally used to initialize global variable if they are not exist. If global variable are not exist in system then it will create new one or else assign value if its value is NULL.

:SYSTEM.TRIGGER_ITEM vs :SYSTEM.CURRENT_ITEM

Both :SYSTEM.TRIGGER_ITEM and :SYSTEM.CURRENT_ITEM has character string values which is in form of BLOCK_NAME.ITEMN_NAME. :SYSTEM.TRIGGER_ITEM represents the Item in the scope of firing trigger. When :SYSTEM.TRIGGER_ITEM is referenced in KEY-XXX triggers then only it returns the values same as :SYSTEM.CURSOR_ITEM. :SYSTEM.CURSOR_ITEM represents currently focused item and may change in a trigger if navigation takes place. Value of :SYSTEM.TRIGGER_ITEM remains same from begining of trigger till end.

Performance Guideline-Use a PL/SQL variable instead of a bind variable

Use a PL/SQL variable instead of a bind variable. Referencing a bind variable that represents a forms item (such as :DEPT.DEPTNO) requires forms to find the item in its internal list. Therefore, each time your code uses that same bind variable, the lookup has to occur again. If you have code that uses the same bind variable more than once in the PL/SQL block, create a variable instead. For example, the following code stores the value of :DEPT.DEPTNO in a variable and references that variable instead of repeating a lookup to find the value.
For Example,
DECLARE
v_deptno NUMBER := ept.deptno;
BEGIN
message('The department # is ' v_deptno);
IF v_deptno < 0
THEN
message('Incorrect department number');
...;
END IF;
--
:control.department_num := v_deptno;
END;

Global Variables

Introduction to Global Variables:
Global variables in Oracle forms are the variable which are accessible thruout system (or entire runform session) until we erase it. You can declare these global variables anywhere in PL/SQL code (Triggers or Program Units). Main advantage of using global variables is that using global variable is very easy and simple. On the fly you can declare any number of variables. Value of global variable is preserved for whole runform session. In Oracle 10g forms you can store up to 4000 BYTES of CHAR data, while in previous version it was limited to 255 BYTES CHAR only.
Declaration of Global variables Variables:
In Oracle form style of declaring global variable is quite different than normal PL/SQL variables. PL/SQL variable are always declared in Declaration section of PL/SQL code, while you cannot declare global variables in declaration section. Global variables are initialized by assigning value to them.
e.g.
1) Declaring PL/SQL local Variable
declare
cMyName VARCHAR2(30);
begin
cMyName :='James Bond';
........;
..........;
END;
2) Declaring Global variables:
BEGIN
:Global.myName:='James Bond'; -- Globals are prefixed by ':Global.'
.....;
.....;
END;
Remember that DATATYPE for global variable is always CHAR. So if you are assigning DATE, NUMBER data to global variable and reassigning these global values to any other variable having Datatype other than CHAR, there is always overhead of implicit data-type conversion. If you are using global variables heavily in your system then always take care that you erase global variables after use. Since One global variable requires 4000 BYTES size in Oracle 10g Forms and 255 in previous version, your application will consuming too much amount of memory for global variables variables. It reduces performance drastically.
Removing/Erasing Global variables:
You can remove global variable and release its memory by using 'ERASE' Build-in.
ERASE('Global.myName');
Referencing a global variable that has not been initialized through assignment causes a runtime error.