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"
