On 19 Oct 2006 12:15:44 -0700, corey_bunch@yahoo.com wrote:

>You know what Joe - I got 3/4 of the way through a lengthy email to you
>explaining the issue, and in the process I've found the
>problem....might be difficult to explain.
>
>Basically - I've got a pair of subscription classes that are sort of
>married together. When a certain data condition is triggered,....the
>procedure
>a) disables subscription #1
>b) inserts an event for subscription #2, which notifies the user
>
>...bascially to let the user know, hey this subscription (#1) has now
>been disabled. So my problem was, though - subscription #2 was never
>disabled. So then my tester was receiving the same email each day
>saying that subscription #1 had been disabled.
>
>I'd like to still disable #2, but I can't do it in the same procedure,
>b/c my notification engine hasn't picked up the subscription #2 event
>yet.
>
>Confused yet?
>
>Joe Webb wrote:
>> Corey -
>>
>> I haven't seen this myself.
>>
>> If you care to send me the ICF and ADF, I'll see if I can repro.
>>
>> Joe
>>
>>
>>
>> --
>> Joe Webb
>> SQL Server MVP
>> http://www.sqlns.com
>>
>>
>> ~~~
>> Get up to speed quickly with SQLNS
>> http://www.amazon.com/exec/obidos/tg/detail/-/0972688811
>>
>> I support PASS, the Professional Association for SQL Server.
>> (www.sqlpass.org)
>>
>>
>> On 28 Sep 2006 12:13:36 -0700, corey_bunch@yahoo.com wrote:
>>
>> >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
>> >> http://www.sqlns.com
>> >>
>> >>
>> >> ~~~
>> >> Get up to speed quickly with SQLNS
>> >> http://www.amazon.com/exec/obidos/tg/detail/-/0972688811
>> >>
>> >> I support PASS, the Professional Association for SQL Server.
>> >> (www.sqlpass.org)
>> >>
>> >> On 22 Sep 2006 12:16:20 -0700, corey_bunch@yahoo.com 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