An excellent and simple solution, thank you Misi!!!
- Kelly Logan
> Hi Kelly,
>
> Change your escalation to do the following:
> Action 1: Push-Fields to Scheduler ('1' = $1$) and set status to "Running"
> Action 2: Push-Fields to Log
> Action 3: Push-Fields to Scheduler ('1' = $1$) and set status to
> "Completed"
>
> Each push is commited to the database immediately after completion.
>
> You would, of course, need to remove the Push-Fields Filter attached to
> the Scheduler form.
>
> I tried it, and logged it, and as you can see, each Push-Fields is
> committed to the database immediately:
> http://www.rrr.se/tmp/rrrLogScheduler.html
> Note that I omitted the Push to the Log-form in the test...
>
> Best Regards - Misi, RRR AB, http://www.rrr.se/sv/
>
>> I am working with a scheduling application that uses a one minute
>> interval
>> escalation to review and kick off jobs that are set by users.
>>
>> The problem is that if the job that is kicked off lasts longer than one
>> minute, it might get started multiple times. I am looking to modify
>> this
>> process so that it will start only once.
>>
>> Currently, there are two forms, the Scheduler form and the Log form. On
>> the Scheduler form there are two fields of interest:
>>
>> Status
>> - Waiting
>> - Running
>> - Completed
>>
>> Next Execution (date/time)
>>
>> The Run escalation looks every minute for entries where 'Status' =
>> "Waiting" AND 'Next Execution' < $TIMESTAMP$. Those it finds are set to
>> Status "Running".
>>
>> Filters on the Scheduler form fire for 'Status' = "Running" and create a
>> Log form entry with the pertinent job information.
>>
>> Filters on the Log form fire on Submit and run the job. (For example,
>> setting a process flag on entries of a separate form.)
>>
>> Another escalation on the Log form checks sets their status to Complete,
>> which pushes back to the Scheduler form.
>> ---------------
>>
>> The problem is, if the job is data intensive, it can build a large
>> backlog
>> of pending transactions that the initial Log entry submission and thus
>> the
>> setting of the Scheduler entry 'Status' to "Running" are waiting on. If
>> this goes over one minute, as it now is, the escalation will push in
>> another transaction to change the Scheduler entry and another large
>> backlog of transactions is created. This is bringing my dev server to a
>> whimpering halt.
>>
>> The main problem as I see it is that the once the chain filters starts,
>> the following escalation fires can't see that it has started.
>>
>> Here's my question: If I have a filter in this chain that is set with
>> the
>> `! postfix, will it fire immediately, or will it still be a part of the
>> chain, just before the other latter stage filter actions?
>>
>> For example, if I add a flag field to the Scheduler form and change the
>> Run escalation to modify that instead:
>>
>> Run escalation looks on Scheduler form for entries that have 'Status' =
>> "Waiting" and 'Next Execution' < $TIMESTAMP$
>>
>> Scheduler filter (with `! postfix) fires on 'zTmpStatus' = "Running" and
>> 'Status' = "Waiting":
>> 1.) Set Fields - 'zTmpStatus' to $NULL$ and 'Status' to "Running"
>> 2.) Commit Changes
>>
>> Scheduler filter II (without postfix but with same Run If) fires and
>> creates the Log entry to run the job. Job runs for five minutes.
>>
>> When Run escalation rolls around one minute later, will it see the
>> Scheduler entry with a 'Status' of "Running", or still "Waiting"?
>>
>> Thanks in advance,
>>
>> Kelly Logan
>> Cybernetic Solutions, Inc.
>> [EMAIL PROTECTED]
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
>> the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
