Actually I have done something similar in order to make a different field (in her example Field1) unique (and give a better error message than the one with a field # in it).
The reason for 'requestid' != $requestid$ is so that the filter does not find the current record on modify Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe Martin D'Souza Sent: Monday, November 08, 2010 4:29 PM To: arslist@ARSLIST.ORG Subject: Re: set fields behavior if no requests match filter Looks like what you are trying to do is check if an entry is duplicate before creating a new one? If so I don't quite understand why you are trying to compare the value of the Request ID??? A Request ID (if it is column 1) will never be duplicated on a form. So why compare that? Comparing null value of field 1 and an existing value of field 1 should be more than enough.. Set a field on the current form with a value if a duplicate is found, for eg the Request ID of that value that is found.. If that field is NULL than create a request, if not stop the workflow with an error message.. Joe -----Original Message----- From: lisakemes Sent: Monday, November 08, 2010 5:13 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: set fields behavior if no requests match filter I'm having a hard time even getting to stage one where you are looking for a duplicate value on the same field on the same form. When I create my Filter, I have one Action as well - Set Fields. The Server Name is the correct server name, and the Read Value for Field From is my Form A. I do a Set Field If: 'requestid' != $requestid$ AND 'Field 1' = $Field 1$ AND 'Field 1' != $NULL$, then set another field (like your nonUnique field) to something, save the filter and the Server Name and Read Value for Field From options go back to CURRENT TRANSACTION. It sounds like we are doing the exact same thing, not sure why I can't even get to the stage to at least get my filter to run. I thought you can read a value from the same form. Lisa ARS 7.1 Windows 2003 Oracle 10g AR WUT 7.5 Brien Dieterle wrote: > > Is it normal for a set fields operation, which is set to "Set Fields to > $NULL$" if no records match, to actually set the fields anyway if no > records match? I didn't think so. Here is the scenario: > > I have Form A with a 'Field 1' character field and a 'NotUnique' > character field. I want a set fields operation to, on modify, check to > see if there are any other records in Form A that have the same value as > 'Field 1'. I know this is a great case for a unique index, but lets > just assume that isn't an option. > > So my Filter executes on modify and has one action- set fields. It uses > the Data Source of Server and Form A as the source. The qualification > is something like this: 'requestid' != $requestid$ AND 'Field 1' = > $Field 1$ AND 'Field 1' != $NULL$. In this way I don't care if there > are Nulls that "match", just actual values, and I prevent matching my > own record. > > If no requests match: set fields to $Null$ > if multiple requests match: use first matching request > Set Field: NotUnique = "True" > > So what happens is NotUnique is set to "True" ALL the time, no matter > what. Very, very strange. Here is the kicker: If I change the Set > Field to: > > Set Field: NotUnique = $Request ID$ > > THEN, it works exactly as expected. For duplicate records NotUnique > contains the Request ID of the offending record. If there is no > duplicate, it is null. My guess is it is still broken and trying to set > the field despite no matches, but since there really isn't any value to > get, it sets it to null. Whereas, in the former case I am using a > static string "True" instead of a field name. > > 7.5 patch 1 > > Brien _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
