Nyall,
The key here is that you are trying to trap a specific instance where this
generic error message can come
up and provide a message that you control to give better indication about this
specific situation.
The various suggestions about changing menu styles and such help control what
can be entered, but do
not allow you to specifically address the issue.
Also, there seems to be a constraint about adding anything or doing any
checking on the remote form.
So, all the options here are adding things to the source form only.
The only way to accomplish what you want with a special error message for the
specific case you have is
to do your own validation or trapping of the problem and displaying your own
message.
So, here are some options:
Option 1 -- Easy, quick and dirty however is inflexible
This works ONLY IF you know that there is a bad value -- say 2008A -- that is
causing the problem.
Simply add an active link that fires BEFORE the active link that does the push
to the other form that fires
on the same conditions that has a run if
'field' = "2008A"
and an action that says to display an error message and you can say that value
2008A is not allowed.
You can be as specific as you want with the message.
NOTE: This is easy but it is inflexible since you need to know the exact value
that is wrong and need to
keep up if there are other values that can be wrong. This is an option only if
the menu is essentially
static even though it is a lookup.
Option 2 -- A bit more work, much more robust and flexible than Option 1 but
still requires keeping
definitions in sync
Add (or use an available existing) temp field. It doesn't matter what the
field is since you are really not going
to be using it, you are just going to do a NULL test on it.
Add two active links that run BEFORE the active link that does the push to the
other form that fire on the
same conditions
#1 if the field in question has a value (no need to test if it is NULL),
perform a set fields that has a qualifier
that is the same as the qualifier for the menu that is on the other form with
the following added on
AND 'field on target form' = $field on current form$
This does the same search for a subset of records to display AND says to see if
there is one that is the
value I am supplying.
Assign the field value you are looking up to the temp field you have arranged
for with the option for what to
do if there are no matches set to "Assign a NULL value"
#2 runs at a higher execution order than #1 has a run if
'temp field' = $NULL$
and an action that is an error message that says exactly what you want to say.
This adapts to any value and changing menus. However, it is dependent on the
qualification. So, if the
menu definition on the other form changes, you will have to change the active
link set fields qualifier in
#1 to adapt.
Option 3 -- requires AR System 7.1 or later, is the most complete solution, but
is also a bit more work
Redo your logic to move the push fields to a filter that fires on "Service".
Then, change the active link that
does the push to perform a Service action against your form (probably passing a
code in some field to
tell it that this is the operation you are performing in case there are
multiple service conditions) and have
the operation performed.
At this point you have the IDENTICAL operation you have now but instead of the
active link performing the
operation, it calls an operation on the current form and a filter performs the
operation. But, the error is the
same and you still want it fixed.
HOWEVER, this is where you can then use the second new feature of 7.1 -- error
handling (available only
for filters which is why I had to get you to move the operation to filters
first).
Define an error handler on the filter that does a push. If an error occurs
during the push, the error handler
will get called.
The error handler would have a run if qualification of
$ERRORNUMBER$ = 306 AND $ERRORMESSAGE$ LIKE "%536870913%"
(note that the actual keywords are different strings, but you can look up
the exact wording)
This would be true ONLY for error 306 on the field of interest.
Success, the error handler would not be called
Any other error and the error handler would run the ELSE branch (which is
empty) and return the error
If it matches however, the error 306 would be suppressed completely. You would
then have an action on
your error handler filter that would be an error message of the text that you
wanted to have.
Essentially, you have trapped the error you don't want in this case and
substituted your error. You could
alternatively have kept running or whatever you wanted but you wanted an
alternate error.
This last one is the most work, but it works no matter what the values are
today or change to, no matter
what the menu in question is.
I hope this shows the variety of types of things you can do to handle
situations like the one you are
describing and that there are often different options -- with different
implementation costs -- that you can
choose from depending on what you want to accomplish and how far you need to go
with the solution.
I hope this set of ideas gives you something to think about and that helps with
your situation,
Doug Mueller
________________________________
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of MCCAVITT Nyall
Sent: Wednesday, May 27, 2009 12:52 PM
To: [email protected]
Subject: Re: Need to make an error message more friendly.
Hi Joe,
Tried that but as the Pattern attribute is set to $MENU$ then this gives the
same error.
What I am trying to do is catch the error and displayed a more user-friendly
error message.
Thanks.
Nyall
_____________________________________________
Nyall McCavitt CND/COE/VI/SQ (BE.25) Tel: +33 (0)1 69 88 73 02
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Joe DeSouza
Sent: mercredi 27 mai 2009 20:58
To: [email protected]
Subject: Re: Need to make an error message more friendly.
**
You do not have to change the Menu type.. just the field property of the field
that the menu is attached to.
You will find this option in the first default tab of the field property in the
mid upper right corner of the field property dialog..
Joe
________________________________
From: MCCAVITT Nyall <[email protected]>
To: [email protected]
Sent: Wednesday, May 27, 2009 1:29:20 PM
Subject: Re: Need to make an error message more friendly.
Hi Joe,
Unfortunately I cannot change the menu type as it is based on a search of
another form.
Thanks.
Nyall
-----Original Message-----
From: Action Request System discussion list(ARSList) on behalf of Joe DeSouza
Sent: Wed 27/05/2009 17:41
To: [email protected]
Subject: Re: Need to make an error message more friendly.
Make the character menu's display type as drop list and you will never have to
deal with that error..
Joe
________________________________
From: MCCAVITT Nyall <[email protected]>
To: [email protected]
Sent: Wednesday, May 27, 2009 10:38:25 AM
Subject: Need to make an error message more friendly.
**
Hi,
Environment: ARS V7.1 (Solaris) running with a remote Oracle 10g database.
One of my users has complained that the standard error message from Remedy for
a certain condition is not very user-friendly and I cannot see an easy way of
making the message more friendly. Any suggestions would be welcome.
The simplified situation is this:
One one form, called A1, for this example, I have a field called 'Menu' which
has a menu attached to it. The values in this menu are 2008A, 2008B, 2008C and
2008D. There is a button on this field which when clicked on copies the data
from form A1 to form A2 by means of an Active Link. This second form also has a
field called 'Menu' with an attached menu, but in the case the menu values are
2008B, 2008C, 2008D i.e. the value 2008A is missing from the menu on the form
A2.
When an entry is being created on form A1 with a value of 2008A in the 'Menu'
field and then the button is clicked on the user receives the following error
message:
ARERR [306] Value does not fall within the limits specified for the
field : (Pattern - $MENU$) : 536870913
The error message itself is clear enough as to why the error has occurred but
the problem is that is uses the Database ID to identify the field where the
problem is. This is OK for an Administrator but the user would like to have the
name of the field i.e. the database label value. Personally I would like to
have the database label value, the form name and the data value that has caused
this error.
Thanks in advance.
Nyall
_____________________________________________________________
Nyall McCavitt CND/COE/VI/SQ (BE.25) Tel: +33 (0)1 69 88 73 02
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
