Misi, I would agree with you if all that my tool did was accept Remedy basked queries, but it accepts SQL queries which can be quite a bit more complex utilizing all of the SQL capabilities to identify which records to remove....for example, you can issue an SQL query that tells it to delete all of the orphaned Task records....something that a Remedy Query simply wouldn't be able to identify.
On Mon, Jul 24, 2017 at 5:26 AM, Misi Mladoniczky <[email protected]> wrote: > ** > Hi, > > Converting the LJ delete tool to a filter plugin seems a little bit > pointless as you have the run process equivalents of > Application-Delete-Entry and Application-Query-Delete-Entry already at hand > in filters and escalations. > > Using escalations to search for your records followed by > Application-Delete-Entry > for every row is best in most circumstances where you are dealing with a > lot of data. Using Application-Query-Delete-Entry will process all records > within a single transaction, which might tax your system... > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) > * 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 > > July 22, 2017 2:51 PM, "LJ LongWing" <[email protected] > <%22lj%20longwing%22%20%[email protected]%3E>> wrote: > > ** > Thomas, > Yes...it could be done as an API Filter Plugin....I've been thinking about > that since you asked....the only problem I can see with a Filter Plugin > would be the feedback portion. As it is, running it, you get the feedback > in the log about what was attempted, what was executed, etc...I could > output all of that to the plugin log through normal channels if that would > be ok....I'd just never thought of doing it through a plugin before.... > On Sat, Jul 22, 2017 at 2:02 AM, Thomas Miskiewicz <[email protected]> > wrote: > > ** > LJ, > can we have your tool as a API Filter plugin? > Thomas > > On 21. Jul 2017, at 23:29, LJ LongWing <[email protected]> wrote: > > ** > Harsh, > Deleting from the DB will always be faster than deleting from the > applications server because you are removing the overhead of the Remedy > server, that being said however, I always do my deletes against the app > server. I do this for many reasons, but data integrity is one of them. When > you do your deletes through the app server, you get 'all' of the pieces > that you are supposed to get (T, H, B, BNCN)....for this reason, deleting > though the app server is preferred, from my perspective at least. With this > thought in mind, I have produced a tool that I have used personally for > several years, and with the assistance of Jason Miller, moved more > mainstream and increased performance from it by making it multi-threaded. > http://remedylegacy.com/tools/delete-requests/ > This tool uses an SQL query to identify the records that need to be > removed, and then uses the api to do the actual removal. Because it's using > the API, it'll make any workflow that fires on delete fire, which can cause > you do have a cascade effect cleaning up parent/child/grandchild/etc > relationships.... > In general, I recommend not doing anything with the Remedy DB directly at > the DB level, there are of course all sorts of people that do with no > impact at all, or no noticeable impact, but in general, having done Remedy > for as many years a I have....I believe the data should be inserted into, > modified, and removed from the Remedy DB by the Remedy application server... > On Fri, Jul 21, 2017 at 2:56 PM, Harsh <[email protected]> wrote: > > ** Hi All, > Today i got into an argument where one of > my colleague was deleting 57K records from custom form through > Escalations. I asked him to better use a delete query on arsystem database. > As it will delete the records faster then escalations. > As per him both will take same amount of time. But i believe escalation > will take more time as it has to make a call to DB everytime and somehow > will add the processing time on the server. > Please let me know your thoughts upon the same. > Thanks, > Harsh > > > -- > *Thanks & regards* > *“Harsh Chaudhary”* > *"Impatience never commanded success**"* > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
