|
Home > Archive > MS SQL Server > December 2005 > Notification Services - Where's the Magic?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Notification Services - Where's the Magic?
|
|
| Cameron 2005-12-29, 9:23 am |
| I've been reading articles and working with the samples and tutorials for a
few weeks now on 2005 Notification Services and I'm just not seeing the big
gain. Can someone please explain how and why this is a useful tool to
implement rather than build by hand? It seems that all the work requires
hard coding the data changing events in the procs which do the work. So say
I update a ActiveFlag from 0 to 1, and I need to send an email to the user to
say their record has been activated. What about notification services sees
that data change and tosses an event? I don't want to use a trigger or code
the proc that does the bit change, I want NS to see it and do everything.
I'm clearly missing something. As a follow up, the interfaces I build for
users to create subscriptions have to be hard coded for each specific type of
notification, because it needs to tie back to each instance of a service.
Isn't that a really bad way to program in terms of scalability? I appreciate
the help, thanks for reading.
| |
| Jeff A. Stucker 2005-12-29, 11:23 am |
| Thanks for your question.
You might get a better response on this topic by posting to the
microsoft.public.sqlserver.notificationsvcs group.
--
Cheers,
'(' Jeff A. Stucker
\
Senior Consultant
www.rapidigm.com
"Cameron" <Cameron@discussions.microsoft.com> wrote in message
news:FD1018AB-B93F-40C8-B9A0- 9B3B0982FA5F@microso
ft.com...
> I've been reading articles and working with the samples and tutorials for
> a
> few weeks now on 2005 Notification Services and I'm just not seeing the
> big
> gain. Can someone please explain how and why this is a useful tool to
> implement rather than build by hand? It seems that all the work requires
> hard coding the data changing events in the procs which do the work. So
> say
> I update a ActiveFlag from 0 to 1, and I need to send an email to the user
> to
> say their record has been activated. What about notification services
> sees
> that data change and tosses an event? I don't want to use a trigger or
> code
> the proc that does the bit change, I want NS to see it and do everything.
> I'm clearly missing something. As a follow up, the interfaces I build for
> users to create subscriptions have to be hard coded for each specific type
> of
> notification, because it needs to tie back to each instance of a service.
> Isn't that a really bad way to program in terms of scalability? I
> appreciate
> the help, thanks for reading.
|
|
|
|
|