microsoft.public.sqlserver.notificationsvcs
[Top] [All Lists]

Re: Duplicate Notifications

Subject: Re: Duplicate Notifications
From: Joe Webb
Date: Wed, 04 May 2005 17:19:00 -0500
Newsgroups: microsoft.public.sqlserver.notificationsvcs
David - 

Can you take the configuration files to another server and build the
instance/application there to see if you can repro the problem? That
would also allow you to use the debugging sprocs as Shyam has
suggested to further troubleshoot the problem.

Also, can you post a better psuedo-code version of your match rule? 

-- 
Joe Webb
SQL Server MVP


~~~
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 Wed, 04 May 2005 18:10:28 -0400, David Van de Vate
<[email protected]> wrote:

>Shyam Pather [MSFT] wrote:
>
>> David,
>> I noticed that in your rule, you select from two tables whose names both
>> indicate "events":
>> 
>> FROM  MyEvent  s INNER JOIN
>>                                  MyEventEvent e ON (e.SelectRuleID =
>>  s.SelectRuleID)
>> 
>> Is "MyEvent" really your subscription class name?
>> 
>> When you say "run the rule in QA", do you mean that you use the NS
>> debugging stored procedures (NSSetQuantumClock, NSPrepareRuleFiring,
>> NSExecuteRuleFiring) or do you just copy & paste the rule and run it? If
>> the latter, then I imagine you have to edit some of the names in the FROM
>> clause because the NS-defined views won't exist or be populated with the
>> right data, so you aren't running *exactly* the same query.
>> 
>> I suggest you use NSSetQuantumClock to set the quantum clock back to a
>> quantum in which you saw the duplicate behavior. Then execute
>> NSPrepareRuleFiring - that will set up all the state, just as NS does when
>> it executes your rule. Then you can look at the actual event and
>> subscription views that NS uses and see if they contain the data you
>> expect.
>> 
>> Thanks
>> -shyam
>I pseudo-coded the rule to mask proprietary information.  Let's suffice it
>to say that the rule is a straightforward (just like the examples) join 
>between the subscription view and the event view.
>[email protected]
>The problem we are experiencing is in a production environment that limits
>my options with respect to resetting quantum clocks and the like.
>
>When I change the names of the views to the underlying tables (Subscription
>and Event) and execute the rule in Query Analyzer, I get distinct rows
>back.  However, the notification table has exactly (never more) 2 duplicate
>rows for each notification.
>
>Same batch, same rule firing, consequtive NotifcationIDs.
>
>I've been working with NS for sometime and am pretty handy about digging
>through the tables to piece things together. This issue has me at a loss.
>We have unique events;unique subscriptions; but we end up with duplicate
>notifications.
>
>We are using Digest Delivery.  I wonder if the NSNotify xsp or whatever
>factors that in, is someome how generating the duplicates.
>
>Any help is much appreciated.  
>
>David Van de Vate


<Prev in Thread] Current Thread [Next in Thread>