Option 4 would be to not store a literal representation of a moving target (a text label) but instead store a constant reference to the value. This would require that you alter the way you think about storing data within your applications; to achieve this, things need to be normalized and you need to enforce constraints [1] to the extent the system allows.
Consider the following design: - the character field (with the menu) where the user selects the value is a display only field - the value returned from the menu is a primary key from another form (a guid or entryid or some other value) - you have a separate optional/required field (hidden) that stores the foreign key - on menu select, you translate that foreign key the menu returns by retrieving the literal representation and placing it in the display-only field (active link) and moving the foreign key to the hidden field - you have filters that perform validation on the create of the record or modify of the foreign key to check the foreign key is valid Added advantages: 1. Native AR form searches work as you would like. 2. It is simply not possible to get a bad value into the field, so subsequent modify operations will not trigger an error. 3. Should you want to change a menu value at some point in the future, it is reflected everywhere without updating 'potentially' millions of values (think of values like login name or full name or email address). This has a potentially huge impact on (a) the consistency and reliability of your data and (b) the potential bottlenecks the system will run into should you need to modify these values 4. It's efficient (for updates, validity checks, ...) 5. It's reliable; bad data simply won't get in (through changes to the source data, changes to the referencing data, ...) Footnotes: 1. This means that once a key is defined, it can not be removed without cleaning up all references; this is typically achieved using a cascading delete. This could also be achieved by having mechanism that (a) update references to another key or (b) nulls all key references Axton Grams On Wed, May 27, 2009 at 3:25 PM, Mueller, Doug <[email protected]> wrote: > ** > 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 > > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
