Hi,
If you create the record through the normal user interface such as ARUser.exe
or Mid-Tier, or via a Push-Fields, there will normally not be any zero-length
strings, only NULL.
If you submit through an API-programs or some other means, it might be
possible to send a zero-length string instead of a NULL.
How do you create the records?
If this is your actual problem, you might want to create a preceding filter
that sets it to NULL if it is "". This way you will know if this is causing
your problem by looking at the log.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Hi Misi,
>
> thanks for answer. I've already done this as well - remove Run If
> Qualification and it doesn't help. I even export this FLTR to def file and
> look how it looks in def fiel, just in case if this could be problem with Dev
> Studio.
>
> No, my fields don't have name like 1.1, but I've changed names for purpose of
> this message. Although it is good to know about such situation which can occur
> if we use field name with dots - I didn't know about such "future" ;) But I
> think this will only happen when we use name only with numeric and dots
> without latters, as your given example '15.1.2'.
>
> Yesterday I tested one more option - empty value in 'Field1.1' instead of NULL
> value. This also suggested me LJ LongWing on BMC Community. After change
> qualification from:
> ('Field1.1' != 'DB.Field1.1') AND ('Field1.1' != $NULL$)
> to:
> ('Field1.1' != 'DB.Field1.1') AND ('Field1.1' != $NULL$) AND ('Field1.1' !=
> "")
>
> record are not created since yesterday. I will be watching this weird
> situation. If this suspicions will confirm then I will ask programmer to
> change API program which update value in 'Field1.1. It looks like this program
> update this field even when nothing has changed.
>
> Best regards,
> Piotr
>
> Dnia Poniedziałek, 19 Stycznia 2015 11:04 Misi Mladoniczky <[email protected]>
> napisał(a)
>> Hi,
>>
>> I don't know...
>>
>> I would try to remove the Run-If, Save the FLTR and then add the Run-If
>> manually using field IDs instead of field names.
>>
>> Do you really have the "1.1" etc in your field names? There are situations
>> where specifying dots have a meaning to separate different fields, such as
>> when referencing the different Status-History values. For example '15.1.2'
>> would mean the 'Status-History.Assigned.Time'. The currency fields also have
>> special meaning for dots.
>>
>> So if there is a bug in your version of DevStudio, using field ids might fix
>> your problem: ('536870913' != 'DB.536870913' AND '536870913' = $NULL$)
>>
>> The text will change back to database names when you save, but the values
>> stored in the DB might be different. You can verify this by exporting a
>> FLTR-DEF-file before and after you do this.
>>
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>>
>> > Hi Guys,
>> >
>> > I have two weird situations, maybe the reason is obvious but I'm focus on
>> my
>> > code and don't catch this. So I hope you can help me or suggest what to do
>> :)
>> >
>> > First I will describe my workflow and then I will describe my problem with
>> it.
>> >
>> > There is a regular 'Form1' with character optiona 'Field1.1'.
>> > To this form is connected 'FLTR1' executed on Modify with qualification:
>> > ('Field1.1' != 'DB.Field1.1') AND ('Field1.1' != $NULL$)
>> > 2 actions:
>> > - Set Field
>> > From Name:'Form2'
>> > Qualification:('Field2.1' = "Value") AND ('Status2' = "Active") AND
>> > ('Field2.2' = $Field1.1$)
>> > If No Request Match:Set Fields to $NULL$
>> > If Multiple Request Match:Use First Matching Request
>> > Mapping: 'tmpField1.2'=$Request ID2$
>> > - Call Guide 'Guide1' Table Loop:None
>> >
>> > Filter Guide "Guide1" has only one 'FLTR2' which is also related to
>> 'Form1'
>> > but without execution, with qualification:
>> > 'tmpField1.2' != $NULL$
>> > 1 action:
>> > - Set Field
>> > Form Name:'Form2'
>> > Qualification:'Request ID2' = $tmpField1.2$
>> > If No Request Match:Set Fields to $NULL$
>> > If Multiple Request Match:Use First Matching Request
>> > Mapping: 'Field1.3'=$Field2.3$
>> > 1 else action:
>> > - Push Field
>> > Form Name:'Form2'
>> > Qualification:('Field2.1' = "Value") AND ('Status2' > "Active") AND
>> > ('Field2.2' = $Field1.1$)
>> > If No Request Match:Create a New Request
>> > If Multiple Request Match:Take No Action
>> > Mapping: 'Status2'="Pending"
>> > 'Field2.1'="Value"
>> > 'Field2.2'=$Field1.1$
>> >
>> > So when value in 'Field1.1' on 'Form1' has been changed, but is not NULL
>> then
>> > workflow should check whether such value already exist on 'Form2' in
>> > 'Field2.2' and if yes then take value from 'Field2.3' from 'Form2' and set
>> to
>> > 'Field1.3' on 'Form1'.
>> > If such value doesn't exist on 'Form2' then records should be created.
>> >
>> > It is typical situation - so it should work without any problem. But it's
>> not,
>> > for some reason 'FLTR1' is fire even when 'Field1.1' is NULL and it causes
>> > create on 'Form2' record with NULL value in 'Field2.2'.
>> > Update on 'Form1' is done by API. When I try simulate this situation by
>> > preparing test workflow which push data to 'Form1' to 'Field1.1' NULL
>> value it
>> > works fine - 'FLTR1' doesn't fire. When I push some value to 'Field1.1'
>> then
>> > workflow also work fine - check whether such value exist and if no create
>> new
>> > record on 'Form2' but with value in 'Field2.2'. Also when I push directly
>> to
>> > 'Form2' to 'Field2.2' with value NULL then my troubleshoot filter fire and
>> > send to me notification about this.
>> > So it looks like problem exist only when it is done by API program.
>> >
>> > To troubleshoot this issue I've created filter on 'Form2' which should
>> execute
>> > on Submit, Modify when 'Field2.2'=$NULL$ and send to me notification about
>> > such situation. It is strange because although records are created with
>> > 'Field2.2'=$NULL$ the FLTR doesn't pass the qualification (I see it in the
>> > logs).
>> >
>> > This weird issue can be seen in gathered logs (FLTR, SQL and API):
>> > Server API log:
>> > /* Sat Jan 17 2015 16:10:00.0412 */+SE ARSetEntry -- schema Form1
>> entryId
>> > 100000000000001 from Unidentified Client (protocol 14) at IP address
>> > 192.168.0.1
>> > /* Sat Jan 17 2015 16:10:02.7688 */-SE OK
>> >
>> > Server FLTR log:
>> > /* Sat Jan 17 2015 16:10:02.6351 */ <Filter Level:0 Number Of
>> Filters:311>
>> > Checking "FLTR1" (500)
>> > --> Passed -- perform actions
>> > 0: Set Fields
>> > tmpField1.2 (536871628) =
>> > 1: Call Guide "Guide1"
>> > /* Sat Jan 17 2015 16:10:02.6367 */ <Filter Level:0 Number Of
>> Filters:312>
>> > Checking "FLTR2" (500)
>> > --> Failed qualification -- perform else actions
>> > 0: Push Fields -> "Form2
>> > <deferred to phase 2>
>> > /* Sat Jan 17 2015 16:10:02.6370 */ Call Guide "Guide1" (return)
>> > ...
>> > /* Sat Jan 17 2015 16:10:02.7076 */ End of filter processing (phase 1)
>> --
>> > Operation - SET on Form1 - 100000000000001
>> > /* Sat Jan 17 2015 16:10:02.7077 */ Restart of filter processing
>> (phase 2)
>> > -- Operation - SET on Form1 - 100000000000001
>> > /* Sat Jan 17 2015 16:10:02.7079 */ <Filter Level:0 Number Of
>> Filters:391>
>> > Checking "FLTR2"
>> > 0: Push Fields -> "Form2"
>> > <deferred from filter FLTR2>
>> > Status2 (7) = 1
>> > Field2.1 (8) = Value
>> > Field2.2 (536871075) =
>> >
>> > Server SQL log:
>> > /* Sat Jan 17 2015 16:10:02.6354 */SELECT T1017.C1 FROM T1017 WHERE
>> ((T1017.C8
>> > = 'Value') AND (T1017.C7 = 0) AND (T1017.C536871075 = '')) ORDER BY 1 ASC
>> > /* Sat Jan 17 2015 16:10:02.6362 */OK
>> > /* Sat Jan 17 2015 16:10:02.6412 */SELECT C1 FROM T517 WHERE C1 =
>> > '100000000000001'
>> > /* Sat Jan 17 2015 16:10:02.6421 */OK
>> > /* Sat Jan 17 2015 16:10:02.7082 */SELECT T1017.C1 FROM T1017 WHERE
>> ((T1017.C8
>> > = 'Value') AND (T1017.C7 > 0) AND (T1017.C536871075 = '')) ORDER BY 1 ASC
>> > /* Sat Jan 17 2015 16:10:02.7094 */OK
>> > /* Sat Jan 17 2015 16:10:02.7103 */UPDATE arschema SET nextId = nextId + 1
>> > WHERE schemaId = 1017
>> > /* Sat Jan 17 2015 16:10:02.7111 */OK
>> > /* Sat Jan 17 2015 16:10:02.7112 */SELECT nextId FROM arschema WHERE
>> schemaId
>> > = 1017
>> > /* Sat Jan 17 2015 16:10:02.7118 */OK
>> > /* Sat Jan 17 2015 16:10:02.7119 */INSERT INTO T1017
>> > (C2,C7,C8,C536871075,C3,C5,C6,C1) VALUES
>> > ('X',1,'Value','',1421511002,'X',1421511002,'200000000000002')
>> > /* Sat Jan 17 2015 16:10:02.7158 */OK
>> > /* Sat Jan 17 2015 16:10:02.7159 */INSERT INTO H1017 (entryId,T0,U0,T1,U1)
>> > VALUES ('200000000000002',1421511002,'X',1421511002,'X')
>> > /* Sat Jan 17 2015 16:10:02.7167 */OK
>> > /* Sat Jan 17 2015 16:10:02.7168 */COMMIT WORK
>> > /* Sat Jan 17 2015 16:10:02.7203 */UPDATE T517 SET
>> > C536871733='',C5='X',C6=1421511002 WHERE C1 = '100000000000001'
>> > /* Sat Jan 17 2015 16:10:02.7217 */OK
>> > /* Sat Jan 17 2015 16:10:02.7228 */COMMIT WORK
>> >
>> >
>> > Problem has been observed in the ARS 7.5.00.
>> >
>> > What do you think about this? What could be the reason?
>> >
>> > Cheers,
>> > Piotr
>> >
>> > _______________________________________________________________________________
>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> > "Where the Answers Are, and have been for 20 years"
>> >
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
