Re: DBMS_ALERT or DBMS_PIPE???

Use replication. Any other way doesn't work when user rolls back transaction. You'll receive a message through dbms_pipe or utl_smtp when actual update (insert, delete) was made, not after commit. If transaction is rolled back, you still have a message, without actual change. dbms_alert is not usable, it puts a lock on alert until commit or rollback. The result is that nobody else can write into the same alert until first session commited or rolled back. If you put dbms_alert into table trigger, it's equal to locking the whole table for each dml statement. The behavior is described in the body of the script which creates dbms_alert. It's not in documentation, though.

Alex Filonov

"Daniel A. Morgan" <damorgan_at_exesolutions.com> wrote in message news:<3CA4D0EF.D70F48A2_at_exesolutions.com>...
> One way would be to use an after insert or update or delete trigger firing
> off an email using UTL_SMTP. That's if you just need to be notified. If you
> want to maintenance included you are looking at replication.
>
> Daniel Morgan
>
>
>
> markag wrote:
>
> > Hi all,
> >
> > Here is my situation:
> >
> > I have 2 databases, Development and Live. There are a group of base
> > tables on the both databases that need to have the same records in them.
> > Essentially, they are 'support' tables for the application. I need a way
> > to be notified when a developer changes a record on the development
> > database (unfortunately, they need this ability for efficient
> > development) in any of these tables so that when I do an update I add
> > the changed row of data to the live database or at least log it
> > somewhere.
> >
> > What is the best way to do this?
> >
> > --
> > Posted via dBforums
> > http://dbforums.com
Received on Mon Apr 01 2002 - 12:55:48 CST