Hi,
Yes You are right. Record on 'Form1' is updated by API-program and probably
this program set zero-length string instead of a NULL. My problem is that that
I don't know what API-program update records on 'Form1', so I will need to find
source. Now when I know that it was problem with empty string I can set
appropriate Run If Qualification in FLTR, before that I thought that maybe some
Remedy workflow push data to this form with a NULL value. But I went through
all workflow and I did't find such
workflow.
I even created mimic workflow which pushed NULL value or empty string to
'Field1.1' but it caused that previous qualification [('Field1.1' !=
'DB.Field1.1') AND ('Field1.1' != $NULL$)] of FLTR works fine. I didn't realize
that it could behave different in Remedy clients vs API-program - that empty
string is treated differently.
One more time thanks Misi for help!
Have a nice day!
Best regards,
Piotr
Dnia Poniedziałek, 19 Stycznia 2015 13:36 Misi Mladoniczky <[email protected]>
napisał(a)
> 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"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
