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"
