Hi,
No, but I have no reason to believe it differs.
I have not seen discrepancies in that way ever. And I have done a lot of
log file reading...
I think the record is returned, but the COLMAX()-function or
table-field-cache-memory has some problem or is accessed in a buggy way.
Best Regards - Misi, RRR AB, http://rrr.se
> Have you tried to catch the SQL sentence at the database side?
>
> One month ago I saw one SQL sentence at the log that was different to the
> one received by Oracle (it involved a shared workflow with a missing
> field).
>
> Jose M. Huerta
> Project Manager**
>
> Movil: 661 665 088
>
> Telf.: 971 75 03 24****
>
> Fax: 971 75 07 94****
>
> <http://www.sm2baleares.es/>****
>
> SM2 Baleares S.A.
> C/Rita Levi ****
>
> Edificio SM2 Parc Bit****
>
> 07121 Palma de Mallorca****
>
> <http://es-es.facebook.com/pages/SM2-Baleares/158608627954>
> <http://twitter.com/#!/SM2Baleares>
> <http://www.linkedin.com/company/sm2-baleares>
>
> La información contenida en este mensaje de correo electrónico es
> confidencial. La misma, es enviada con la intención de que únicamente sea
> leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje
> por otras personas no está autorizado, por lo que en tal caso, le rogamos
> que nos lo comunique por la misma vía, se abstenga de realizar copias del
> mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de
> inmediato.****
>
> P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es
> necesario.
>
>
>
> On Wed, Jun 27, 2012 at 4:19 PM, Misi Mladoniczky <[email protected]> wrote:
>
>> Hi,
>>
>> Now I have another problem with almost the same workflow. It does not
>> work
>> even though I run it as an admin.
>>
>> I can see the SQL-code executing in the SQL-log within my filter.
>>
>> But the COLMAX($ColSelectionValue$) returns empty, even though the
>> single
>> match contains a value.
>>
>> I have done the exact same things manually in Remedy User with a
>> table-field-refresh. The SQL code is identical, and I get exactly one
>> hit...
>>
>> Anyone else seen strange behaviour like this?
>>
>> This is from the API/FLTR log:
>> ...
>> <FLTR> <Filter Level:1 Number Of Filters:11> Checking "MOB:NT/svc-132
>> Cell
>> Set Cellkategori" (132)
>> <FLTR> --> Passed -- perform actions
>> <FLTR> 0: Set Fields
>> <SQL > SELECT T370.C1,C536870913,C536871068 FROM T370 WHERE
>> ((T370.C8 = '738122') AND (T370.C536870958 = 'DK') AND
>> (T370.C536871068 >= 1) AND (NOT (('F2925' LIKE '[^ ]%')) OR
>> (T370.C536870913 = 'F2925'))) ORDER BY 1 ASC
>> <SQL > OK
>> <FLTR> Cellkat (600043039) =
>> <FLTR> <Filter Level:1 Number Of Filters:12> Checking "MOB:NT/svc-141
>> Ownership Start" (141)
>> ...
>>
>> This is the SQL code from my manual Remedy User table refresh. It is
>> identical:
>> <API > +GLEWF ARGetListEntryWithFields -- schema MOB:ÄomfJoinCell from
>> Remedy User (protocol 18) at IP address 10.20.7.167
>> <SQL > SELECT T370.C1,C536870913,C536871068 FROM T370 WHERE
>> ((T370.C8 = '738122') AND (T370.C536870958 = 'DK') AND
>> (T370.C536871068 >= 1) AND (NOT (('F2925' LIKE '[^ ]%')) OR
>> (T370.C536870913 = 'F2925'))) ORDER BY 1 ASC
>> <API > -GLEWF OK
>> One record was returned with a value in the column I was interested in.
>>
>> Note that all testing was performed as an Admin user.
>>
>> Best Regards - Misi, RRR AB, http://rrr.se
>>
>> > Hi,
>> >
>> > Very interesting. I wonder about the reasons for this "design"...
>> >
>> > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> 2011)
>> >
>> > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> > * 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,
>> >>
>> >> Some years ago I had a similar problem in ARS 7.1. The answer was:
>> >> "works
>> >> as designed" and they created a defect to correct the manuals. But I
>> >> never
>> >> verified if BMC modified their manuals.
>> >>
>> >> SW00301166 -- Doc bug: Server Side Table loop requires access
>> >> permission
>> >> on supporting table form REF ARS 7.1 Worfklow Objects Pg15
>> >>
>> >> KR Conny
>> >>
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Action Request System discussion list(ARSList)
>> >> [mailto:[email protected]] Im Auftrag von Misi Mladoniczky
>> >> Gesendet: Mittwoch, 20. Juni 2012 19:51
>> >> An: [email protected]
>> >> Betreff: Re: Filter Table Refresh differ if Admin User...
>> >>
>> >> Hi,
>> >>
>> >> I missed this feature too... I usually read the release notes quite
>> >> thoroughly, but I did not see this. Which version was it introduced?
>> >>
>> >> RRR|Log does not strip out anything from the logged lines, but in
>> this
>> >> case I checked the setting for Data Access -> Get Data As, and it is
>> set
>> >> to "System", not "User". So it seems like this is actually a bug
>> then...
>> >>
>> >> AR System 7.6.04 SP2.
>> >>
>> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> >> 2011)
>> >>
>> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> >> * 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.
>> >>
>> >>> Fred,
>> >>> That is an interesting feature I didn't know existed....
>> >>>
>> >>> Misi,
>> >>> A few choice notes from the workflow guide, page 303
>> >>>
>> >>> Workflow Functions
>> >>> In addition to the Set Fields, Push Fields, and Call Guide actions,
>> >>> setting Get Data As to User affects the workflow functions COLCOUNT,
>> >>> COLAVG, COLMIN, and COLMAX.
>> >>> These functions operate over the columns in a table field. When
>> >>> performed in a guide that was called by a filter with the Get Data
>> As
>> >>> User set, the entries and fields used to populate columns in the
>> table
>> >>> field are limited to those visible to the calling user.
>> >>>
>> >>> And almost more importantly
>> >>>
>> >>> Filters with Get Data As set to User are identified in the filter
>> log
>> >>> file by the string "with data retrieval as user userName."
>> >>>
>> >>> So...being all we have access to is your RRR|Log parsed
>> >>> portions....did this text display in the filter log? Is the filter
>> in
>> >>> question set with this restriction?
>> >>>
>> >>> If your answer to either of those questions is No...then we have a
>> bug
>> >>> somewhere...I don't recognize 'MOB'...is that a custom application?
>> >>>
>> >>> -----Original Message-----
>> >>> From: Action Request System discussion list(ARSList)
>> >>> [mailto:[email protected]] On Behalf Of Grooms, Frederick W
>> >>> Sent: Wednesday, June 20, 2012 6:54 AM
>> >>> To: [email protected]
>> >>> Subject: Re: Filter Table Refresh differ if Admin User...
>> >>>
>> >>> Actually if you look at a filter in Developer Studio 7.6.04, in the
>> >>> Properties you will see
>> >>>
>> >>> + Change History
>> >>> - Data Access
>> >>> Get Data As
>> >>> + Full Text Search
>> >>> + Help Text
>> >>> + Integration Workflow
>> >>>
>> >>> And the choices for Data Access are: System | User
>> >>>
>> >>> Fred
>> >>>
>> >>> -----Original Message-----
>> >>> From: Action Request System discussion list(ARSList)
>> >>> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
>> >>> Sent: Wednesday, June 20, 2012 3:52 AM
>> >>> To: [email protected]
>> >>> Subject: Re: Filter Table Refresh differ if Admin User...
>> >>>
>> >>> Hi,
>> >>>
>> >>> It turned out that if I changed the permission on the table and
>> >>> underlying join form, the table got refreshed.
>> >>>
>> >>> This definitely seems like a BUG, as filters should ALWAYS run with
>> >>> administrator privileges...
>> >>>
>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> >>> 2011)
>> >>>
>> >>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> >>> * 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 LJ,
>> >>>>
>> >>>> Thank you for the input.
>> >>>>
>> >>>> In this specific case, the table is never refreshed.
>> >>>>
>> >>>> And I am not doing a table loop, just a Set-Fields with a COLSUM().
>> >>>>
>> >>>> And the really strange thing is that the behaviour differ depending
>> >>>> on the users permission groups...
>> >>>>
>> >>>> I agree that there is need for more control over the filter tables!
>> >>>>
>> >>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> >>>> 2011)
>> >>>>
>> >>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> >>>> * 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.
>> >>>>
>> >>>>> Misi,
>> >>>>> I can't speak directly to your situation, but I have seen in the
>> >>>>> past that server table loops don't necessarily refresh the table
>> >>>>> every time you do something with them...I have done loops before
>> >>>>> where the table has a dynamic qualification, and you set the field
>> >>>>> that makes it dynamic, then utilize the table...then within the
>> same
>> >>>>> transaction, you change that qual, and try again and it doesn't
>> >>>>> necessarily refresh the table even though the qual, and thus the
>> >>>>> contents should change. Without a 'refresh table' option in
>> >>>>> filters, I've never quite been sure how to get it done.
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Action Request System discussion list(ARSList)
>> >>>>> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
>> >>>>> Sent: Tuesday, June 19, 2012 8:34 AM
>> >>>>> To: [email protected]
>> >>>>> Subject: Filter Table Refresh differ if Admin User...
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I have a 7.6.04 SP2 system, where I am having inconsistent
>> behaviour
>> >>>>> in filters depending on if you are an Admin user or not.
>> >>>>>
>> >>>>> This is an outline of the stuff involved 1. API Call Create Entry
>> 2.
>> >>>>> Filter makes Service Call 3. Filter performs a Set-Fields from a
>> >>>>> Table Column, which should always trigger a table refresh
>> >>>>>
>> >>>>> This is the same workflow as non-admin user, followed by an
>> >>>>> admin-user
>> >>>>> (Demo):
>> >>>>> http://rrr.se/tmp/rrrlog-service-table-refresh-problem-nonadmin.html
>> >>>>> #
>> >>>>> goto
>> >>>>> http://rrr.se/tmp/rrrlog-service-table-refresh-problem-admin.html#go
>> >>>>> t
>> >>>>> o
>> >>>>>
>> >>>>> I have some times seen strange behaviour inside of
>> >>>>> filter-service-calls.
>> >>>>> This could be related to that.
>> >>>>>
>> >>>>> How is a person to make sure that tables in filters are refreshed
>> >>>>> properly?
>> >>>>>
>> >>>>> Any comments?
>> >>>>>
>> >>>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList
>> MVP
>> >>>>> 2011)
>> >>>>>
>> >>>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> >>>>> * 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.
>> >>>
>> >>>
>> >>>
>> >>> ______________________________________________________________________
>> >>> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> >>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >>>
>> >>> ______________________________________________________________________
>> >>> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> >>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >>>
>> >>
>> >>
>> _______________________________________________________________________________
>> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend
>> wwrug12
>> >> www.wwrug12.com ARSList: "Where the Answers Are"
>> >>
>> >>
>> _______________________________________________________________________________
>> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> >> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >>
>> >
>> >
>> _______________________________________________________________________________
>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >
>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
