Tip on "bogus" frm-42100

Question

I've had this happen to me a couple times. As soon as a form
starts if you have an on error trigger that does display_error, you
get frm-42100. So it appears like a bogus error, as if the on-error trigger
were fired when there was no error. If you try to avoid displaying the
error_code 42100 that doesn't work either. In my case I found that
what actually happened was there was an error in the when-new-forms-instance
trigger. This occurred because some code in there tried to set an
item that was query only before enter-query mode. I think that the error code
is apparently lost before the on-error trigger fires. Or something. Anyway
I thought I'd mention it that if someone was plagued by this check out the
form level triggers.
Personally I am really having problems with things like this. As another example:
"FRM-30113: Block must have non-query-only database item. Cause:  A block that allows updating and inserting must have at least one item derived from the database. Action:  Create a derived item in the block."
What on earth does that mean? What is a "derived item"? I had huge problems
with this error and the actual cause was in the block the dml data target type
was set (by default by forms). Apparently that isn't acceptable with a query only block. What I'm wondering is if there is a third party
tool that makes forms development easier?

Answer 1

Ok well I thought logged meant like "logged" as in we "logged an error". silly me :-) Oracle could certainly save itself and the customers a lot of trouble by changing some of this legacy confusing terminology: "logged" for database, "derived" for database IMHO.
And further display error doesn't admit to putting out frm-42100:
"Displays the Display Error screen if there is a logged error. When the operator presses a function key while viewing the Display Error screen, Oracle Forms redisplays the form. If there is no error to display when you call this built-in, Oracle Forms ignores the call and does not display the DISPLAY ERROR screen. " Nothing about frm-42100
in there and more importantly it doesn't say that it only displays database errors
which is what I think people are saying is the case. Consequently how would someone know that?
According to the on-error trigger doc:
"Use the ERROR_CODE , ERROR_TEXT , ERROR_TYPE , DBMS_ERROR_TEXT , or DBMS_ERROR_CODE Built-in function in an On-Error trigger to identify a specific error condition. "
So people are saying display error only displays dbms_errors? So that an on-error
trigger, which catches both error_code errors and dbms_error code errors, would have to also display on it's own the error_* errors but could use display_error to display the dbms_errors? Is that the plan? (The reason for using display error is some terribly vague
error messages that go to the screen otherwise that don't even indicate what table is involved, much less what record. Because of that one needs to display the insert/update statement to have any clue what is failing.)
Regarding " your FRM-30113 error (Thank you for including all the text!!!)"
As I said, the cause was not the lack of a database item in the block. The
cause was not having the block property DML DATA Target Type set to table.
These dml properties have been giving me a lot of grief. And to find that out
I had to login to metalink and do a search. Oh so painful! ow! ow! :-)
But another case I found where the dml data target type can get you is
a join in a relation join causing:. "FRM-30415: Relation's detail block is a control block. Cause: A master-detail relation specifies a detail block that's a control block. Action: Specify a detail block that's a database block. "
The vagueness of that advice is the problem. The docs need to be more specific regarding where forms is getting it's ideas regarding this now that these other properties
exist. So my advice is if a person is getting some weird complaint about something
being a control block that isn't a control block check the dml data target type.
(And last but not least why cant you have a master block that is a control block?
It seems perfectly reasonable to me :-)