tip on "bogus" frm-42100

lake · Jul 14, 2007 10:29PM

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?

508145 · Jul 14, 2007 11:14PM

Thanks for the FRM-42100 tip.

What is a "derived item" [in the block]?

A derived item is an item that is associated with a database field. A derived item is more commonly called a database item or base table item.

Sm-Kng-Oracle · Jul 15, 2007 1:07AM

I dont think it is a 'BOGUS' error.You need to generate frd log file to determine what is causing this error in ur form

Message was edited by:
user448926

user346369 · Jul 15, 2007 2:05AM

It would be really nice if you would supply the text along with an error code. Saves others the nuisance of looking up FRM-42100 and finding that the text is:
FRM-42100: No errors encountered recently.

Then if you would read the on-line Forms help about Display_Error, the first sentence is:
"Displays the Display Error screen if there is a logged error."

Unfortunately, there are many things implied in the documentation, and sometimes it is difficult to figure things out. A "logged error" is an error received from the database as a result of your form issuing a SQL statement.

There are two distinct types of errors handled by Forms: database errors (the "logged errors"), and Forms processing errors. There are many many things you can try to do in your form that are illegal or incorrect that the Forms runtime will not process. If you do one of them, you will get a runtime FRM error message. The FRM errors are not "logged errors" since they do not come from the database.

Whenever you get a runtime error that is not from the database, using Display_Error will result in your getting FRM-42100. And THAT is not bogus. What is bogus is your asking to see the nonexistent database error.

- - - - - - - -

Now for your FRM-30113 error (Thank you for including all the text!!!)
A "derived item" is a base-table column that you select into your block. It sounds like you had all the items' Database Item property set to No. A block based on a database table requires at least one column from that table.

lake · Jul 15, 2007 8:08PM

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 :-)

lake · Jul 15, 2007 8:11PM

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 :-)

508145 · Jul 15, 2007 9:27PM

The FRM errors are not "logged errors" since they do not come from the database.

Aren't these FRM errors coming from the database?

FRM-40501: ORACLE err - unable to reserve record for update or delete
FRM-40502: ORACLE err - unable to read list of values
FRM-40505: ORACLE err - unable to perform query
FRM-40506: ORACLE err - unable to check for record uniqueness
FRM-40507: ORACLE err - unable to fetch next query record
FRM-40508: ORACLE err - unable to INSERT record
FRM-40509: ORACLE err - unable to UPDATE record
FRM-40510: ORACLE err - unable to DELETE record
FRM-40512: ORACLE err - unable to issue SAVEPOINT command
FRM-40513: ORACLE err - unable to get date/time from database
FRM-40504: ORACLE err - unable to execute a gname trigger
FRM-40511: ORACLE err - occurred while executing a gname trigger

508145 · Jul 15, 2007 9:41PM

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.

I will admit the the help documentation is not always consistent in its terminology (e.g., derived item, base table item, data item, database item, etc.). I don't think it's intuitive that a "logged error" in Forms refers only to a database error, and I doubt a novice would know this. The context seems to imply a "logged error" is a Forms error logged internally. I don't think the term "logged error" appears anywhere else in the help documentation. Sadly, the glossary provides little help to the novice either since these terms are not defined.

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

The underlined seems to indicate that Forms will ignore the call and not generate a "FRM-42100 No errors encountered recently".

Message was edited by:
Mark Roberts

user346369 · Jul 16, 2007 2:09AM

We who use Forms day in and day out actually have much more experience with the product than those who wrote the on-line help. Whoever those people are, you can be sure they are off working on some other product by now.

Oracle could certainly improve a lot of things in Forms, but they have declared Forms a mature product, and are not investing very much in furthering its scope.

382441 · Jul 16, 2007 5:36PM

I just want them to fix the error: "object cannot be updated" when the object is a #@$#@ button and I accidently pressed a letter on the keyboard. Who really thinks they can type on a button? It's not an error.....A mature product should not make a mature person like myself, cry and moan like a little boy....eh.

Forum Stats

Quick Links

Categories

tip on "bogus" frm-42100

Comments

Data

Databases

Development

Development Tools

Open Source

Programs

Forum Stats

Categories

tip on "bogus" frm-42100

Comments