[Top] [All Lists]

Re: Chronicles

Subject: Re: Chronicles
From: "andyjax"
Date: Thu, 7 Jul 2005 12:32:12 -0700
Newsgroups: microsoft.public.sqlserver.notificationsvcs
Yes I have your book. I lightly read over chapter 6, but it did not seem to 
address my needs. Is is bad to join to the 
NS<NotificationClassName>Notifications table directly? If I join it, then 
that will cause more overhead, but seems to be the way to eliminate 
duplicates. I will take a look at the other samples.


"Shyam Pather [MSFT]" wrote:

> Hello,
> I seem to remember you saying you had a copy of my book. If that's so, 
> you'll find a detailed discussion of chronicles in Chapter 6. They're also 
> covered in the books online and, I think, the stock sample that comes with 
> the product.
> The gist of it is that you can define arbitrary tables to hold state for 
> your application. Chronicles can be associated with event classes or 
> subscription classes. Event class chronicles are updated by chronicle rules 
> that you define in the ADF as part of the event class. These rules look 
> similar to match rules, but rather than generating notifications, they 
> simply update whatever state you keep in your chronicle tables, based on the 
> latest event data. Subscription chronicles are updated as part of the 
> regular match rules.
> To handle the duplicate notifications scenario as you've described it, you 
> could keep a subscription chronicle that holds information about which 
> subscribers were notified about what. You update this table every time you 
> generate a notification. In your match rule, you join in this table and use 
> it to filter out rows that you don't need to notify about again. There are 
> many variations of this e.g. never send duplicates, send a duplicate if a 
> certain amount of time has elapsed, send a duplicate if some data value has 
> changed beyond a threshold etc. All can be handled via chronicles.
> -shyam
> -- 
> Learn more about SQL-NS: 
> ---------------------------------------------
> This posting is provided "AS IS" with no warranties, and confers no rights. 
> Use of included script samples are subject to the terms specified at 
> ---------------------------------------------
> "andyjax" <[email protected]> wrote in message 
> news:[email protected]
> > Ok my mind is becoming mush after reading so much.
> >
> > I seem to recall that notifications can leverage chronicles to eliminate
> > duplicate notifications for an event, such that key information that might 
> > be
> > triggered is only sent if what was sent before is different.
> >
> > I cannot seem to find the reference to this. Any direction would be
> > appreciated. 

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