>Hi,
>One of our developers has developed a trigger which does the following.
>
>1) A web app is running built in .Net instead of having the user press refresh to update he decided he want it built in a "push" manner so.
>2) He maintains a indexing service on a seperate machine that keeps an index (also build it .NET) and it has a web service interface to update the index.
>3) whenever a record is changed it sends a request to the web service to tell it which record is changed to update it.
>4) the back end is db2/sqlserver/oracle so he built a trigger on every table that calls the web service to notify changes to the indexing service.
>
>If I run an update which updates 80 records than 80 calls to the web service is made this takes about 13 seconds (the update time with the web calls is under 1 second).
>
>I'm not really keen on this design does anyone have any suggestions about how to convince him this is a bad idea or any alternative ideas.
>
>Thanks Tim

The performance degredation should be enough to convince him it is a bad idea.

An alternative - and a more correct way of solving the problem - is to use MSMQ Microsoft Message Queue instead of a web service. However, creating a notification trigger on every table is still a very bad idea.