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:
> 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.
> 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.