Hi,
The MidTier and ARUser.exe both translates all empty strings to NULL and also
strips LEADING and TRAILING spaces off strings.
Therefore I think it good practice to have all API-programs do the same.
Best Regards - Misi, RRR AB, http://rrr.se
> 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 <m...@rrr.se>
> 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 <m...@rrr.se>
>> > 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
