Hi Axton,
A table solution will still be done within the same database transaction,
and potentially produce a very large and slow rollback chunk in the DB.
An escalation on the main table will do one transaction per entry found,
which can make it faster and less resource consuming.
I suggested the join-form-solution if you wanted to switch your
escalations on and off through data, as you suggested in your design
pattern.
Best Regards - Misi, RRR AB, http://rrr.se
> Actually... I guess I was not clear enough...
>
> Each of these special processes take other parameters that drive how they
> work.
>
> Application-Delete-Entry <form_name> <entry_ID>
>
> verses
>
> Application-Query-Delete-Entry <form> <qualification_string>
>
> The first special process only deletes a single record at a time based
> on the <entry_ID> used.
> While the second one could delete zero or all records in a single form
> at a time based on the <qualification_string> value used.
>
> If someone wanted to they could even add a table field (to the
> "ESC-controler" form) to get a list of field 1 values based on an
> EXTERNAL() operator search of the form (using the advanced table field
> features to make the form name part of the "ESC-controler" record)
> and then call the "Application-Delete-Entry <form_name> <entry_ID>"
> function inside a table looping filter guide too. (But that just seems
> like many extra trips to the DB to me.
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
>
> On Jan 8, 2008 3:12 AM, Misi Mladoniczky <[EMAIL PROTECTED]> wrote:
>> Tadeu,
>>
>> Just a small warning.
>>
>> The "Application-Query-Delete-Entry" will do the delete of all records
>> in
>> a single transaction. For example if you run this once a day, you will
>> probably match a lot of records. If you in addition have attachment
>> data,
>> the the transaction rollback data can become very big.
>>
>> If you run an escalation directly on the archive form, or a join-form
>> connected to the "trigger record", it can do an
>> "Application-Delete-Entry"
>> instead for each record in turn.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>
>> Products from RRR Scandinavia:
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> * RRR|Translator - Manage and automate your language translations.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>>
>> > Tadeu,
>> >
>> > I know in another thread you said this issue is already resolved, but
>> > I wanted to throw out another idea for you too. Your Escalation does
>> > not need to run on the "Archive form" at all. But it can still delete
>> > data in the Archive form.
>> >
>> > I like the design pattern of having your Escalations fire based on
>> > finding a "trigger record" in a form. This allows you to turn on/off
>> > your Escalations with data instead of an Admin tool change. Then you
>> > can build filters/workflow on this "ESC-controler"(Modify) form that
>> > will do what you want/need for that escalation. For example you can
>> > first get a count of the records that will be deleted, and maybe even
>> > run an external process to do a "backup" for that same search
>> > qualification, then use the Application-Query-Delete-Entry special
>> > process to actually remove the data from one or more forms as part of
>> > the same process. If you build your workflow in enough of a data
>> > driven/generic way then you can likely schedule all of your data
>> > backups/deletions from this same "controller form". (And once you move
>> > to v7.1 you can have multiple Escalations pools to not block other
>> > Escalation activities too. :) )
>> >
>> > HTH.
>> >
>> > --
>> > Carey Matthew Black
>> > Remedy Skilled Professional (RSP)
>> > ARS = Action Request System(Remedy)
>> >
>> > Love, then teach
>> > Solution = People + Process + Tools
>> > Fast, Accurate, Cheap.... Pick two.
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
