here
is my answer.
-Original Message-From: Andrey Bronfin
[mailto:[EMAIL PROTECTED]]Sent: Thursday, November 28, 2002
12:34 PMTo: Multiple recipients of list ORACLE-LSubject:
a PL/SQL design question.
Andrey Bronfin wrote:
> Dear gurus!
> I'm looking for a solution to the following problem:
> I need a way to run a certain stored procedure as soon as a record is
> inserted into a certain table.
> A trigger is not feasible for this, since I do not want the execution of the
> procedure to be a part
Andrey
Please forgive me if this sounds like a theoretical solution, since I don't
have the time to try it out relevant to your situation.
But what about using the trigger to call a procedure which is an autonomous
transaction ? You do this by placing the following anywhere in the declare
secti
Similarly, if you only want the procedure to be run IF
the base transaction does a commit then you can use
dbms_job (because the job submission process is part
of the same txn)
hth
connor
--- Stephane Faroult <[EMAIL PROTECTED]> wrote: >
Andrey Bronfin wrote:
> > Dear gurus!
> > I'm looking for
Thanks a lot !
-Original Message-
Sent: Thursday, November 28, 2002 8:04 PM
To: Multiple recipients of list ORACLE-L
Andrey Bronfin wrote:
> Dear gurus!
> I'm looking for a solution to the following problem:
> I need a way to run a certain stored procedure as soon as a record is
> inserte
Hi !
The problem with this solution is that the row, inserted into my table, will
be committed (i.e. seen by other users) only after the completion of the
stored procedure called by the trigger.
Thanks a lot !
-Original Message-
Sent: Thursday, November 28, 2002 9:09 PM
To: Multiple recipi
Hi,
The other option that you have is to use Advance Queuing. You can insert
the row and a message on a queue within the same transaction. Your
procedure will be a consumer of the messages in the queue.
If the transaction that does the insert is rolled back then the message is
never placed on t
Title: RE: a PL/SQL design question.
An easy way to do this is using DBMS_JOB. That way you can get asynchronous execution, and it isn't tied to the transaction.
This is clipped from a fix I just did for a customer. It ain't complete, but hopefully you can follow
Title: RE: a PL/SQL design question.
Just
so you know, you should be able to manually "acknowledge" the enqueue of the
message on the queue which will make it available to the
consumer before the transaction containing the insert is
commited.
-Original Message-Fr
Title: RE: a PL/SQL design question.
Jeremy, as I wholeheartedly agree that dbms_job is a good thing, here is my recent experience ...
One of the development group recently posed us the question "Can we use a db trigger to fire a dbms_job to be executed only once?" we reluctan
Title: RE: RE: a PL/SQL design question.
Dear Richard,
These are a bunch of developers who think they are "GOD" (at-least their managers think so) ... we have learned that it is better to let them try and fail themselves rather than trying to explain them the right thing ... it
Title: RE: RE: a PL/SQL design question.
I'd like to add a point here as well...
Because DBMS_JOBS are asynch, ie not transaction bound and not read-consistent, by design they should not be allowed to be fired from triggers or other event-driven mechanisms _if_ they are to accomplish
12 matches
Mail list logo
