Spurious FRM-40405 while committing changes

[David Blethen]

I'm looking for anyone who may have seen this before. Here are the
specifics:
I'm running forms 4.5 (Developer 2000) against an Oracle 7.3 database.
When committing changes (do_key('commit_form');), I receive a FRM-40405
message ("No changes to apply") followed by the normal FRM-40400 message to
indicate that the transaction is complete and the correct number of records
have been applied and saved. The spurious 40405 comes after the
POST-FORMS-COMMIT trigger would have fired and before the
POST-DATABASE-COMMIT trigger would have fired (tested by posting alerts in
each of these triggers to track the flow of processing as the commit takes
place). The only thing that is supposed to happen between these two triggers
is that the actual commit gets sent to the database. According to the forms
documentation, the 40405 message shouldn't even come until later in the
process flow. I tried using an ON-COMMIT trigger to overide forms default
processing, but that had no impact on the message. The message still comes
after the ON-COMMIT trigger has finished. Changing the SAVEPOINT mode (form
level) from true to false had no impact. At the time the commit_form is
called, only one of my blocks has a CHANGED status. All others are either
NEW or QUERY status.

I'm sure that my users will be both confused and annoyed by this message.
Has anyone seen this before? Does anyone have any ideas of what else I might
look at?

Thanks,
David B.

[David Blethen]

I had one helpful hint, but it didn't change the message. There is one
explicit post in the form. I have commented that out and the message still
comes up. Any other ideas? Thanks again,
David Blethen

David Blethen <dble...@bhe.com> wrote in message
news:38282...@news.cybertours.com...

[David Blethen]

In case anyone is interested ... I was looking in the wrong place, but I
finally found the problem. The spurious 40405 messages were the result of
the fact that this is a multi-form application. Several forms stay open at
the same time. Among other changes that I made, I changed the open_form call
to "no_session" rather than "session". At the time I did not catch the fact
that as a result, a commit on any open form caused the system to attempt to
commit all open forms. Since nothing was changing on the other forms, they
were returning a "No changes to apply" message (40405). I couldn't find the
40405 message on form I was working with because the form I was looking at
wasn't raising the error. Instead, it was being raised on the background
forms and when I got back to back messages, the message line pushed the
message to an alert box. Once I identified the cause, I could actually
switch between forms and see the 40405 message on the message line of each
form. As a former DBA, I don't want multiple sessions out there so I want to
leave the open_form as "no_session". The workable but not elegant solution
that I came up with was to put an ON-ERROR trigger at the form level on all
forms to trap the 40405 message.