Oracle Forms Debugging: Using the “DEBUG_MESSAGES=YES” runtime option - Handling "Please Acknowledge" message

Oracle Forms Debugging: Using the “DEBUG_MESSAGES=YES” runtime option - Handling "Please Acknowledge" message

“DEBUG_MESSAGES=YES” is a “quick and dirty” technique for pinpointing code problems. This causes a message to automatically display to let you know each trigger as it executes. Once you encounter the runtime error, you will know the last trigger that fired and should be able to trace through the code from that point. For anyone that was around in the SQL*Forms 3.0 days, this was the default behavior when running a form in debug mode.

To use this option from the Form Builder, check the “debug_messages” option on the runtime tab after choosing Tools -> preferences from the menu. From the command line, simply add the “debug_messages=yes” option. 

If you are using an icon in Windows to start your form, add the option to the shortcut command. It would look something like this for Windows platforms:

c:\orant\bin\ifrun60.exe module=myform userid=scott/tiger debug_messages=yes

On Unix:

f60runm module=myform userid=scott/tiger debug_messages=yes

The major disadvantage of using this technique is that you have to acknowledge every message as each trigger executes, which can be very annoying. You will keep getting "Please acknowledge message" prompt each time whenever a new trigger is encountered. Although it shows the triggers that fire, it does not show program units that execute, and there is no way to display the values of variables. It can also cause the same focus problems and program flow interruption that you see with the “MESSAGE” built-in. However, this method is useful if you have no idea which trigger is causing the problem; once you have narrowed down the scope, other troubleshooting techniques would be more appropriate.

Oracle Forms Exception Handling: NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS

Oracle Forms Exception Handling: NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS

EXCEPTION block in PLSQL Oracle Forms is used to track the exceptions. Following is the PLSQL code snippet which uses NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS exceptions. If the SQL SELECT query does not return any data, NO_DATA_FOUND exception is fired. If the SQL SELECT query returns more than one row where it was expected to return only one row, TOO_MANY_ROWS exception can be used to track this kind of exception. If you are not sure what kind of exception can the code throw, use OTHERS exception.

DECLARE
  DEPARTMENT_NAME VARCHAR(60);
BEGIN
  SELECT DEPTNAME INTO DEPARTMENT_NAME FROM DEPT WHERE DEPTNO = 20;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    MESSAGE('No data found');
  WHEN TOO_MANY_ROWS THEN
    MESSAGE('More than one row found');
  WHEN OTHERS THEN
    NULL; -- don't do anything and just return from the procedure
END;

Difference between WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers

Difference between WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers

WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers are very close to each other and create a lot of confusion. Following are three differences between them to clear the picture a little bit.

1. Whenever the user changes the value in the item and tries to move out of that item using ENTER or TAB or MOUSE, WHEN-VALIDATE-ITEM trigger is fired. But, in case of KEY-NEXT-ITEM trigger, if user moves out using MOUSE, it will not fire. So, the validation written on this trigger will not fire. Better use, WHEN-VALIDATE-ITEM trigger in this case as it also works with MOUSE.

2. KEY-NEXT-ITEM trigger fires before the WHEN-VALIDATE-ITEM trigger.

3. KEY-NEXT-ITEM trigger will fire every time you move to the next field from that field but WHEN-VALIDATE-ITEM will fire only when you have acutally made any changes to that item. If you have made no changes in the item, it will not fire when you move out this item.

Personally, I prefer to use WHEN-VALIDATE-ITEM trigger in many situations.

Oracle Forms Tutorials: WHEN-VALIDATE-ITEM trigger

Oracle Forms Tutorials: WHEN-VALIDATE-ITEM trigger

Consider that you have an oracle form on which there is a datablock which uses EMP table. EMP table has a column called SALARY. Now there is a contraint on the SALARY column that it should be greater than or equal to $1000. Your requirement is that whenever any user fills salary in the Oracle Forms ITEM (say ITEM_SALARY) and tabs out from that item, a validation should fire and if the value filled is not valid, it should give you an error message and does not let the cursor go to the other item. In these situations WHEN-VALIDATE-ITEM trigger is used. Following is the PLSQL code you should write on the WHEN-VALIDATE-ITEM trigger of the ITEM_SALARY item.

IF :ITEM_SALARY < 1000 THEN

    MESSAGE('ERROR: Salary must be at least $1000 or more.');

    RAISE FORM_TRIGGER_FAILURE; -- To keep the cursor in the item

END IF;

You should also go through this video on YOUTUBE by Edward Honour.

In this video, he tries to pick the department name when the user enters the department number. If department number does not exist in the database, he shows the error message and does not let the cursor to go to the other item using FORM_TRIGGER_FAILURE trigger. He has used NO_DATA_FOUND exception for showing the error message. Following is the code used in this video:

BEGIN

SELECT DEPT_NAME INTO :BLOCKNAME.ITEMNAME FROM DEPT WHERE        DEPT_NO = :BLOCKNAME.ITEMNAME2;

EXCEPTION

WHEN NO_DATA_FOUND THEN

MESSAGE('Invalid Department Number');

RAISE FORM_TRIGGER_FAILURE;

END

5 Things you should never discuss your manager

5 Things you should never discuss your manager

An employee should be fair and transparent with his manager, but few revelations can spoil your bonding with your manager. Try never ever talking about these things to your manager:

1. Your doubt on manager' decisions - At times, you may want to raise questions on his judgement. Do yourself a favour - give it a pass. You may not know what business pressures he/she is living through.

2. Snooping on manager's life - Every employee wants to check what his or her manager is doing in social life. Don't blow your cover by admitting to doing it unashamed.

3. Office gossip - Never share office hearsay with your manager without checking its truthfulness. Sharing something random that you heard in the cafeteria and reacting to it may get him or her thinking that you are not mature or trustworthy.

4. Your personal secrets - Your life and its constant struggles are for you to handle. Pouring it all out in front of your manager will put you in a vulnerable position.

5. Your expectations from the manager - The manager is mandated to put forward his/her expectations from you. But it does not mean you to go and tell the manager how you evaluate his/her skill sets!