Look at a statement level trigger. Why would you want to update ona rolled
back transaction? The transaction didn't occur so there is nothing to do.
Once it commits it will run based upon what your job interval is in the
init.ora. 1 seconds means the job will run an average of .5 second later.
Jim
--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"Thomas Rask" <thomas_rask_at_hotmail.com> wrote in message
news:kv4ncv806nihufsfuseg5mmvbvkbg4nmom_at_4ax.com...
>
> Thanks,
>
> It looks as a way to get information on committed transactions. It
> doesn't give me information about rolled back transactions. But this
> is not as important as the committed ones anyway.
>
> I am not sure though if it is the nicest way to do this. For instance,
> if a transaction involves hundreds of updates, can I make sure that I
> do not spawn hundreds of jobs? One should suffice.
>
> Can I be sure also that the job is executed immediately after the
> commit?
>
> Thomas
>
>
> N.B. Performance increase of several magnitutes and an unlimited
> number of parallel transactions as far as the index is concerned.
>
> On Wed, 21 May 2003 13:54:37 GMT, "Jim Kennedy"
> <kennedy-down_with_spammers_at_attbi.com> wrote:
>
> >I doubt you really have incredible speed, but why not have a trigger that
> >fires off a dbms_job. The dbms_job won't run unless the transaction is
> >committed.(thus it is part of the transaction)
> >Jim
>
Received on Wed May 21 2003 - 20:16:43 CDT
