Re: No future for DB2

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:42f11bd4$0$11912$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...
> Madison Pruet apparently said,on my timestamp of 4/08/2005 5:27 AM:
>
> > Going back to your original mis-statement....
>
> Going back to your ORIGINAL statement
>
> >
> >
> >>[MP]
> >>1) replicate all of the trigger activity performed on the original table
>
> So, what happens if a trigger in that table changes ANOTHER
> table that is not being replicated? Do the OTHER table's
> changes get replicated as well? Note: you asked for "ALL trigger
activity".

At a minimun the replication solution should be able to either prevent triggers from firing on the target if it is populated by a replication apply, with the assumption (and policing) that all of the tables associated with original transaction is replicated as part of that transaction.

Or the replication solution can allow the firing of triggers on the target node.

Or the trigger can be specified to be always executed if the replication apply is executing.

Or the trigger can be specified not to fire if the apply is executing.

Or the replication solution can detect the differences between the source/target, and only fire the triggers that are unique on the target.

Or all of the updates associated with the trigger would not be replicated, allowing the triggers on the targets to do their stuff.

Or the replication system can detect the differencs in the impact of the trigger firing on the target and rereplicate the extra rows which were created by triggeractivity on the target back to the source.

Or the individual triggers can be 'replication enabled' and informational logging containing the trigger pseudo code can be created for the trigger activity - to be replicated and executed on the target system.

Or the create trigger statement can be changed to contain a clause to prevent it from being fired as a result of replication.

Or the replication solution can dynamically triggers which can cause a problem with replication and dynamically correct the issue by either creating a similar trigger on the target, and/or changing the repplication attributes so that the result of the trigger would be propogated.

All kinds of ways to deal with this problem.

>
> >>2) distinguish between updates on a row and inserts/deletes on the same
> > row?
> >
> >> (If not, then cascade deletes are not properly performed)
> >>3) properly handle cascading updates
> >>
> >>[Noons]If I understand your question correctly, that is not possible
> >>with ANY replication in any database version.
> > Well - it just isn't true.
>
> Well, it just is true. You just do NOT understand the full
> consequences of your requirement 1) above.

Oh, I wouldn't say that. Let's see now how many replication patents and patent-pending am I currently holding? Geesh - keep forgetting. ;-) And just how many customers are employing the solutions that I provide? --- quite a few. Nor does the other
> "responder".

>
> And I also stated that Dataguard indeed can cope with that.
> Something you appear to be forgetting.

OK - now for the other whammy. How much does Dataguard cost? In the IBM Informix database, all of this is part of the base server. No extra charge.

>
> --
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k_at_yahoo.com.au.nospam
Received on Wed Aug 03 2005 - 15:07:10 CDT