This content has been marked as final. Show 22 replies
It means that Oracle Forms will ignore error/warning messages below a certain level. In the online Help of Oracle Forms you can look up any FRM-xxxxx message and see what it's message level is.
The example you give is typically used to suppress the "No changes to save" message that will be raised if there are no pending changes in the form when you issue the commit
On this topic - has anyone else had any problems where the suppression of messages in this way doesn't always work..? I have a piece of code that temporarily sets the message level to 10 before doing a POST, to ensure messages such as 'No changes to apply' don't get shown. It always works fine in client-server 6i, but now that we're migrating to 10.1.2.0.2 (Linux apps server), sometimes - but not always - the messages still come through.
I've seen other postings suggesting problems like this e.g. Re: Unwanted "FRM-40405: No changes to apply" message just wondered if anyone else had encountered it and knew the reason?
I am investigating there very same thing.
I have code where the message level is set to 25 followed by a commit.
As a result of this, in forms 6i, there was no message "No changes to save" however in 10.1.2 now we see this message when we shouldn't.
Can't see much documentation on this issue, or think of any reason why it might have changed.
Well, I'm a little relieved to hear that I'm not going mad..! Our problem seems to be very sporadic - I've not been able to replicate it for a number of days now - but it has definitely come and gone a couple of times. I haven't been able to find any firm mention of this, though, and need to wait until the next time it occurs to pin down that it's definitely a problem with the message suppression. It certainly looks that way, though.
Is your problem intermittent, or does it always occur? Have you tried raising a support request with Oracle..?
I have the problem occurring consistently on a Windows and a linux platform
I have been thinking, surely with something this big, someone else must have had the problem. Forms10 has been out for some time now.
I haven't raised a TAR yet as I have been studying the issue and searching for similar occurences.
I tried to filter out the message using on-error and on-message, but strangely seemed unable to stop it with this mechanism.
I've seen both approaches used, and did wonder if filtering out specific error messages might be the better way - presuming the error numbers never change... :) I might move in that direction anyway - but I notice that Tony has tried that and that hasn't helped either.
Like Tony says, I wonder that more people haven't raised this as an issue - it might be something specific to our configurations / environments, but it's hard to know where to even begin diagnosing this one; I can't think of anything in e.g. formsweb.cfg or the .env files that might be affecting message suppression.
<Scratches head also>
I am with Gerd on Message_Level -- Only in rare occasions do I change it to a level other than zero. I use a PLL_On_Error trigger to capture and improve a number of Oracle messages. It is posted here:
<p>Re: FRM-40735:Pre_Insert trigger raised unhandled exception ORA-20011
Is there a "best practices" for message level? It's been my experience that most of those messages are annoying and don't really add any value. In some parts of our application the level is 5 and then it gets set before and after a commit or something like that to avoid messages. Any new forms that I have created I've set the level to 25 to avoid all the messages that just get in the way. Since message_level is not used the same way throughout our product thought, I have to get what it was before my form opened and then set it back when my form closes. In my opinion I don't think that the message level should be lower than 25 unless debugging.
I do really like the centralized error handler though, and use something similar for known errors, like suppressing "field cannot be updated" when the control that has focus is a button. Who expects you to be able to update a button? Why even tell me that? heh.
Message was edited by:
In my opinion I don't think that the message level should be lower than 25 unless debugging.That is the most dangerous thing I have seen in a long time! What if the form starts failing for a user, yet there is no error message to report? With the proper on-error message handling, it can save you hours helping the user get back up and running. Our most troublesome is the FRM-40735 -- it hides security errors, for example when the user does not have access granted to a particular table. (Check the processing for that error in the PLL_On_Error process I provided in the link above).
Here is my favorite: In a multi-record block, create a new record (use the F6 key-crerec trigger) anywhere in the middle. Then try to click on another record, or use the down-arrow or up-arrow, or tab through all the fields in the block.
With your message level, your user gets no error message.
With proper testing and planning though this is not an issue. The constant barrage of messages that oracle likes to put up is insane. Maybe 25 is too high, but 0 seems too low. Then again the pll error hanlder is probably best, I just never wanted to code all those meaningless error codes(plus the fact that where i work it's near impossible to get standards in place so that everyone does the same thing) and if i'm not mistaken there are some that are near impossible to trap, but maybe I just didn't know enough when I was trying to trap them.
The constant barrage of messages that oracle likes to put up is insane.Well, I can understand that statement. But early on, we started out setting Message_Level to 5. But then we developed the PLL_On_Message procedure below to filter the "informative" messages, and continued on to add the PLL_On_Error in the link I posted above. With those in place, and with Message Level set to zero, we now get ONLY the messages one might want.
I think if you give them a try, you wouldn't be so troubled by Message_Level.
Here is the PLL_On_Message procedure:
PROCEDURE PLL_ON_MESSAGE (MSGN_IN IN NUMBER DEFAULT NULL, MSG_IN IN VARCHAR2 DEFAULT NULL) IS --* -- PLL_On_Message can be called by a form's On-Message trigger, --* -- which fires whenever an "Informative" Type forms message is -- issued by the form. It displays the message, but the -- no_acknowledge parameter prevents it from popping up in an alert -- box if there is another message following. -- MSG_VAL NUMBER := NVL(MSGN_IN,MESSAGE_CODE); MSG VARCHAR2(150) := NVL(MSG_IN,SUBSTR(' '||MESSAGE_TYPE||'-' ||TO_CHAR(MSG_VAL)||': '||MESSAGE_TEXT,1,150)); BEGIN IF MSG_VAL = 40350 --Query caused no records to be retrieved. -- Trap all 'informative' messages resulting from post, commit, -- and commit following post. OR MSG_VAL BETWEEN 40400 AND 40407 THEN NULL; ELSE MESSAGE(MSG,NO_ACKNOWLEDGE); END IF; END PLL_ON_MESSAGE;
Steve's code is very good and helpful, but this doesn't address the main issue which is that there seems to be a change in functionality from Forms 6i/9i to Forms 10g with repect to the message_level eg
system.message_level := '25';
system.message_level := '0';
If you are writing new code, then putting in traps for the on-error and on-message is fine, but if you are migrating code, you want to make as few a changes as possible, so it would be nice to know why you now get "No changes to save" messages in 10g whereas this didn't happen in Forms6i for example. The change of message level was there specifically to avoid getting this message, but now seems to make no difference !!!!