Re: Commit in non-base-table block in Forms 4.0?

Thomas.B.Cox_at_tek.com (Thomas B Cox) writes:

>Okay, this is either trivially easy or subtle, but either way I'm stuck.
 

>I've got a non-base-table block that the user fills out; each item is
>validated against database values. Then they click on a button, and I call a
>stored procedure, passing in parameter values from the block items.
 

>For example, they put in an inventory tracking number, press the button, and I
>call COUNT_INVENTORY ( :my_block.tracking_no ) as a stored procedure call.
 

>But, the stored procedure does not do a COMMIT. I wanted the user to have the
>option of issueing a COMMIT or not.
 

>The only problem I have is, Forms 4.0 refuses to pass the COMMIT command to
>the DBMS, insisting that the form contains no changes to COMMIT.

[...]

>Send e-mail and I will post a summary of responses.

Here are several answers I received. The most straight-forward is:

        forms_ddl ( 'commit' ) ;

Others are:

        How about writing update or insert statment in key commit trigger and after     these statement write commit statment in the same trigger.

    [I believe this suffers the same problem I had originally -- an ON-COMMIT     trigger failed for me earlier.]

I had seen a similar problem with Forms30, i think form does pass the commit command, but since the are no changes in the block, it return the message Form contains no changes to COMMIT, another word if you write on insert triger the would insert somthing to a any database table whether the table is related to the block or not, then press commit,you your form will insert data, and will issue the commit command, but your block did not change. to wrok around this, try setting the SYSTEM.MESSAGE_LEVEL=10, that will suppress the "Form contains no changes..", I am not sure what forms40 use for SYSTEM.MESSAGE_LEVEL.

Finally, if the appropriate packages are installed in Oracle 7.x, any of these will work:

   DBMS_STANDARD.COMMIT ;
   DBMS_TRANSACTION.COMMIT ;
   STANDARD.COMMIT ;

Thanks to those who replied.

 -Tom
thomas.b.cox_at_tek.com Received on Wed Apr 05 1995 - 00:00:00 CEST