Thanks George-- and I should have read the manual: Set Fields to $NULL$—Assigns a NULL value to all of the fields that you are setting (except for fields with static values and keywords).
I just don't understand why one would want it to behave that way-- what if you had a mix of static and retrieved values? You'd have a mishmash. Ah well, I'm sure there is a good reason. :-)
Brien On 10/29/2010 2:58 AM, Payne, George wrote:
Brien, Let me see if I can explain. When you are trying to set the field to a "Static" value, then the CONDITIONS that you're trying to use in the action are not really used because they're irrelavent to the value that you're setting; it's basically like using a SET FIELDS action on the CURRENT FORM. Your second scenario actually has a value that DEPENDS on the conditions, so it works as expected. Now that you have a value in that field (any value will do), then you know if that value in that field is !=$NULL$ then you have a unique record for your search. Good luck, Gp George Payne Corporate Applications Developer Electric Reliability Council of Texas (512) 248-3940 [email protected] ________________________________________ From: Action Request System discussion list(ARSList) [[email protected]] On Behalf Of Brien Dieterle [[email protected]] Sent: Thursday, October 28, 2010 7:58 PM To: [email protected] Subject: set fields behavior if no requests match filter 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
