Re: Forms 4 - 'nothing to commit'

In article <SMUENCH.94Jul5140514_at_doh.oracle.com>, Steven P. Muench <smuench_at_oracle.com> wrote:

> Forms 4.0 *does* go through normal Commit processing when
> encountering the COMMIT or COMMIT_FORM instruction. It will
> loop through all blocks in the form (skipping over blocks that
> don't have a base table and for which no transactional triggers
> exist) and then if there is no action for it to perform (ie no
> changed records from *its* point of view), it will issue the
> error message (FRM-40401: No changes to commit).
 

> In every case, as long as no trigger during commit processing
> raises the FORM_TRIGGER_FAILURE exception, it *will* issue the
> closing database COMMIT instruction.
 

> To avoid printing out this error message to the screen, you can
> either set the :SYSTEM.MESSAGE_LEVEL to '5', then set it back
> to what it was after the successful commit; or, you can write
> an ON-ERROR trigger that evaluate the value of MESSAGE_CODE and
> swallows the message when it is equal to 40401.
 

> I just tried this, and it works correctly in the version of
> Forms 4.0 that I'm running on my machine, 4.0.12.
 

> Hope this helps.
 

>Steve Muench Email: smuench_at_oracle.com

Another idea (this depends on what it is you want to do) is to update the record status of a record to be CHANGED. Even if it isn't.

If any base-table block has a record with a status of NEW or CHANGED, then the COMMIT above will *not* come back with the 'no changes to commit' message. NEW will cause an INSERT, and CHANGED will cause an UPDATE (normally).

If you have a base-table block, but update a non-base-table field, and you want the change in that non-base-table field to get propagated somehow to the database, this is one way to do it.

Cheers.

 -Tom

-- 
    Thomas Cox     tcox_at_netcom.com      503-293-8474
Senior Consultant, Moss Consulting Group, Portland, Oregon