Brien,
I look at it this way. If you were to describe a SetFields with psuedo-code
it would look something like
SET foo = value
where "foo" is the field on the current form, and "value" is what comes from
the other form that you are searching.
For the options that "Set fields to $NULL$", the word 'fields' refers to the
"value" part not the "foo" part. So its the "value" part that is getting
set to null, not foo.
Hopefully that helps some,
Thad Esser
Remedy Developer
---------
Long-winded use cases:
When you have:
SET foo = "StaticText"
then foo gets set to "StaticText".
When you have:
SET foo = value
If you have match foo gets that value.
If you don't have a match, "value" is null, which is what ends up in foo.
When you have:
SET foo = "The value found is: " + value
If you have a match foo gets set to: "The value found is:
WhateverValueWasFound"
If you don't have a match, "value" is null, and foo becomes: "The value
found is: " (note the null at the end).
---------
On Fri, Oct 29, 2010 at 8:36 AM, Brien Dieterle <
[email protected]> wrote:
> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
