Hi,
Yes, it might. I have that as a backup plan myself if my own solution
would stop working. It still works though, and I am starting to think that
this will not change...
Best Regards - Misi, RRR AB, http://rrr.se
> :)
>
> Yes, but after running the round of white box testing, I discovered that
> my
> programmers where using the application-release-pending process at the end
> of service processing.
>
> So I think that I remain on the supported side.
>
> El viernes, 10 de agosto de 2012, Misi Mladoniczky escribió:
>
>> Hi Jose,
>>
>> So you are using the "unsupported" service-database-update stuff anyway
>> ;-)
>>
>> I have found it hard to control filter-table updates.
>>
>> Why not do a double service thing instead. That way the table would be
>> clear each time, and a refresh would be performed.
>>
>> Filter 1: CALL SERVICE-MAX
>> Start SERVICE-MAX
>> Filter x: SET table-max
>> End SERVICE-MAX return table-max
>>
>> Filter 2: CALL SERVICE-DBUPDATE
>> Start SERVICE-DBUPDATE
>> Database Update
>> End SERVICE-DBUPDATE
>>
>> Filter 3: GOTO Filter 1
>>
>> 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,
>> >
>> > I have a table in a form that is used to compute some aggregated
>> funtion.
>> > I
>> > use it inside a loop in a guide. So I check this value several times
>> > during
>> > execution. The content of the table changes, but not the fields used
>> at
>> > the
>> > table qualification. The strange behavior is that ARS only computes
>> the
>> > value at the first iteration, so the value is not correct for second
>> or
>> > next executions.
>> >
>> > To be more clear:
>> >
>> > I have a table with a qualification: 'ParentID' = $Entry ID$
>> >
>> > Then I have a guide with the next filters:
>> >
>> > Label: Loop
>> >
>> > Filter 1: SET
>> > I use a field of the table and compute the MAX.
>> >
>> > Filter 2: CALL SERVICE
>> > I call a service that changes values at the database
>> >
>> > Filter 3: If some condition is meet GOTO Loop.
>> >
>> >
>> > Looking at the log I see that the first time Filter 1 is executed, a
>> > SELECT
>> > is sent to the database, so the MAX value is retrieved correctly.
>> > Then the service executes and I can see the SQL going to the database
>> with
>> > INSERTS and UPDATES followed by a COMMIT WORK. So the Database is
>> > correctly
>> > updated.
>> >
>> > But next time Filter 1 is called, no SELECT to the database is done
>> (seems
>> > that the Server has some kind of Cache and thoughts that the database
>> > hasn't changed)
>> >
>> >
>> > Well, the question: Is there any process command that forces a refresh
>> on
>> > table on filter side?
>> >
>> > Regards,
>> >
>> > Jose Manuel Huerta
>> > http://theremedyforit.com/
>> >
>> >
>> _______________________________________________________________________________
>> > 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"
>>
>
>
> --
>
> 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.
>
> _______________________________________________________________________________
> 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"
