> This looks like the clasic use of a chronology table use inside the
> rule where you would keep track of the specific items you want to
> dissallow. You would use the table in the join to filter out say
> everyone who had recieved a mail on account 123 already then insert
> into the chronology table new rows for those subscribers. The basic
> method is outlined in one of the samples for NS and it can be modified
> to meet your needs. I used it to perform some filtering on larger
> volumn events such that a person would only recieve at most one
> message in any 24hr period, but could also be used without a time
> component to allow only one.
>
> You could trap the subscriberid and categoryid to allow only one per
> category. If you needed to allow for messages only on particular
> state changes you could also trap a status value and allow mail only
> on certain changes from last message to current event (i.e. only send
> mail if the status changed from active to inactive, but not when
> change is back to active)
>
> If there is more than one rule to which the same chronology would
> pertain, I would think that you could leverage the same table accross
> them (I have not tried this myself so no guarantees)
>
> HTH - Tony
>
> "matt roberts" wrote:
>
>> Hi,
>>
>> I am hoping this is a really simple queastion. I haven't come accross
>> it yet in Shyam's book...
>>
>> I want to make sure that people don't get duplicate notifications.
>> For example, if you can subscribe to recieve notifications when
>> records of a certain category are added to the system, I want to
>> allow people to subscribe mutliple times with multiple categories,
>> but make sure that I don't notify the person more than once when
>> something happens. Do I need to add state to my SSNS app?
>>
>> Thanks!
>>

"matt roberts" wrote:

> Thanks very much Tony. A chronology table does indeed look like it will solve
> my problem here.
>
> In addition, I also need to be able to "log" to the database exactly WHO
> recieved a notification and for what, so I think I will be able to kill 2
> birds with one stone, so to speak.
>
> Matt.
>
>
>
>
>
> Hello Tony,
>
> > This looks like the clasic use of a chronology table use inside the
> > rule where you would keep track of the specific items you want to
> > dissallow. You would use the table in the join to filter out say
> > everyone who had recieved a mail on account 123 already then insert
> > into the chronology table new rows for those subscribers. The basic
> > method is outlined in one of the samples for NS and it can be modified
> > to meet your needs. I used it to perform some filtering on larger
> > volumn events such that a person would only recieve at most one
> > message in any 24hr period, but could also be used without a time
> > component to allow only one.
> >
> > You could trap the subscriberid and categoryid to allow only one per
> > category. If you needed to allow for messages only on particular
> > state changes you could also trap a status value and allow mail only
> > on certain changes from last message to current event (i.e. only send
> > mail if the status changed from active to inactive, but not when
> > change is back to active)
> >
> > If there is more than one rule to which the same chronology would
> > pertain, I would think that you could leverage the same table accross
> > them (I have not tried this myself so no guarantees)
> >
> > HTH - Tony
> >
> > "matt roberts" wrote:
> >
> >> Hi,
> >>
> >> I am hoping this is a really simple queastion. I haven't come accross
> >> it yet in Shyam's book...
> >>
> >> I want to make sure that people don't get duplicate notifications.
> >> For example, if you can subscribe to recieve notifications when
> >> records of a certain category are added to the system, I want to
> >> allow people to subscribe mutliple times with multiple categories,
> >> but make sure that I don't notify the person more than once when
> >> something happens. Do I need to add state to my SSNS app?
> >>
> >> Thanks!
> >>
>
>