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"
<<image001.jpg>>
<<image002.jpg>>
<<image003.jpg>>
<<image004.jpg>>
