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"
