SQL*FORMS V3 Block Co-ordination Riddle

-I have a question about an SQL*FORMS V3 riddle that I hope someone can shed some light on.

Consider the scenario of a simple two block master-detail (1-M) one page form. I want the second block to be co-ordinated to the first so use the default block option when creating the second block and tie the second block to the first via the master block and a join condition. So far fine, SQL*FORMS creates all the block co-ordination triggers I need (and which work).

When I look at the triggers and procedures created on my behalf I find the following procedures :-

   DEFINE PROCEDURE

      NAME = check_package_failure
      DEFINITION = <<<
      procedure check_package_failure is
      begin
          if not form_success then
              raise FORM_TRIGGER_FAILURE;
          end if;
      end;


      >>>

   ENDDEFINE PROCEDURE    DEFINE PROCEDURE

      NAME = clear_details
      DEFINITION = <<<
      procedure clear_details ( detail char, master char, opt number ) is
      begin
          go_block(detail);
          check_package_failure;
          if :system.block_status = 'CHANGED' then
              clear_block(opt);
              if :system.block_status = 'CHANGED' then
                  go_block(master);
                  raise FORM_TRIGGER_FAILURE;
              end if;
          end if;
          clear_block;
      end;


      >>>

   ENDDEFINE PROCEDURE    DEFINE PROCEDURE

      NAME = clear_groups_details
      DEFINITION = <<<
      procedure clear_groups_details ( checkmaster boolean, opt number ) is
      begin
          if ( not checkmaster or ((:groups.DIVISION_CODE is not null)) ) then
              clear_details('group_average_fte', 'groups', opt);
          end if ;
          go_block('groups');
      end;


      >>>

   ENDDEFINE PROCEDURE    DEFINE PROCEDURE

      NAME = query_details
      DEFINITION = <<<
      procedure query_details ( detail char ) is
      begin
          go_block(detail);
          check_package_failure;
          execute_query;
      end;


      >>>

   ENDDEFINE PROCEDURE    DEFINE PROCEDURE

      NAME = query_groups_details
      DEFINITION = <<<
      procedure query_groups_details is
      begin
          if ( (:groups.division_code is not null) and :system.record_status !=
       'NEW' ) then
              query_details('group_average_fte');
          end if;
          go_block('groups');
      end;


      >>>

   ENDDEFINE PROCEDURE     One of the typical block co-ordination triggers created by SQL*FORMS is

      DEFINE TRIGGER

         NAME = KEY-CLRREC
         TRIGGER_TYPE = V3
         TEXT = <<<
         clear_record;
         clear_groups_details(FALSE, ASK_COMMIT);
         query_groups_details;
         exception when form_trigger_failure then null;
         >>>

      ENDDEFINE TRIGGER
 

My question is this :-

When a block co-ordination trigger executes

         clear_groups_details(FALSE, ASK_COMMIT);

how does

      procedure clear_groups_details ( checkmaster boolean, opt number )

map ASK_COMMIT to a number parameter and why ?

Am I just becoming senile or am I missing something blatently obvious (and if so I apologize for wasting people's time and bandwidth)

I have displayed the values of 'OPT' in the procedure CLEAR_GROUPS_DETAILS and come up with the following

    ASK_COMMIT - OPT = 8
    NO_COMMIT - OPT = 9 I have Read the Fine Manuals till I'm blue in the face. The example procedures and triggers documented in SQL*FORMS Designer's Reference Version 3.0 (Part 3304-V3.0 0691) are not the same as those produced by SQL*FORMS itself.

We run ORACLE 7.0.16.6.2, SQL*FORMS 3.0.16.12.7 on Vax Open/VMS 5.5-2

Any light anyone can shed on this will be greatly appreciated.

Thanks - Ian
-

+--------------------------+-------------------------+-----------------------+
| Ian Bainbridge           | bainbridge_i_at_bgers.co.uk|Phone: (44) 91-216-0202|
| British Gas ERS          | Newcastle Upon Tyne, UK |            x2790      |
+--------------------------+-------------------------+-----------------------+