My first thought was that a commit is inferred when using Remedy workflow. Unless you're using processes like direct SQL (and I'm not even sure about THAT), I tend to think that they're at least superfluous, and at worst damaging. I'm afraid that you will end up with double commits, because the workflow may not know that the first one has already taken effect unless you do some other extraordinary things in conjunction with the commit.
And if you're going to do all of that, why not just write a stored procedure and run that from ONE Filter? Rick -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Thursday, April 27, 2006 1:06 PM To: [email protected] Subject: Re: SQL COMMIT question Mike, I think I understand your general thinking. However I think your barking up a very wrong tree. So before I start down any possible "how to" ... let me get the trigger point straight..... You mention a "driver table". What are you doing to "trigger" the work on the driver table? (An escalation? A Modify All from the User Tool? , An API program?) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. On 4/27/06, Mike White <[EMAIL PROTECTED]> wrote: > Listers, > > I have an interesting question that one of you may be able to > help with. I have recursive Filters that process records from a > driver table, triggering massive updates to multiple tables (to > distribute a change). As is, it's too large for multiple entries, causing database timeout errors. > Processing records in the driver table one-at-a-time works fine. > > Just before my GOTO (very near the end of the last Filter), I'd > like to insert a Direct SQL COMMIT. As I understand it, the COMMIT > will terminate the transaction and write to disk. I suspect (hope) > that it won't also terminate Filter processing. My goal is to fully > process one record from the driver table, commit my work to clear the > transaction, then return/get next record and continue to the end (with no db timeout). > > Does this make sense? Am I on the right track? > > We're running ARS 6.0.1, patch 1380 on an Oracle 9i database, on > Solaris 5.9. > > Thanks in advance for any insight you can provide! > > Mike White > Office: 813-978-2192 > E-mail: [EMAIL PROTECTED] ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
