Correct - in my match rule, I'm using views only....
INSERT INTO Notification<NotificationClass>(SubscriberId,
DeviceName, SubscriberLocale, ID, blah, blah)
SELECT s.SubscriberId, s.DeviceName, s.SubscriberLocale,
n.ID, n.blah, n.blah
FROM Event<EventClass> n, Subscription<SubscriptionClass> s
WHERE n.ID = s.ID
One thing I'm confused about now - there are two sets of views - one
set are just named what I named the class names in my ADF. I'm using
these to insert the views. Then there's another set that are prefixed
with NS. The NS view is the one I'm updating to be disabled in the
application. Any ideas?
Joe Webb wrote:
> In your match rule, you're joining to the subscription view, not the
> underlying table, right?
> Joe Webb
> SQL Server MVP
> Get up to speed quickly with SQLNS
> I support PASS, the Professional Association for SQL Server.
> On 22 Sep 2006 12:16:20 -0700, [email protected] wrote:
> >Our app goes through & disables some subscriptions using the NS views
> >nightly based on some business rules.
> > UPDATE Notify.dbo.NSSubscriptionClassView
> > SET Enabled = 'Disabled'
> > WHERE blah, blah, blah
> > AND Enabled = 'Enabled'
> >My problem is that these "disabled" subscriptions still seem to be
> >generating matches & sending the messages out. How/Why does this
> >happen??? Where can I begin to debug why this is happening? The
> >underlying table beneath the view gets set properly when I update the
> >view - I've looked at that. An event matched with a disabled
> >subscription should not be generating a notification! Please help.