Although it may indeed work, I'd be reluctant to implement it that
way. SSNS manifests views over tables during processing to improve its
efficiency. By creating one subscriber and subscription, that
processing may or may not do exactly what you intend.
You may want to consider creating a very simple subscriber in SSNS for
each person and then you can join to your external database to get
other information in your match rule, etc.
SQL Server MVP
Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On 8 Dec 2006 14:06:47 -0800, "BigDave" <[email protected]> wrote:
>We would like to take advantage of most of NS 2005's capabilities,
>*except* for it's management of subscriptions and subscribers. (We
>have our own custom DB with subscriptions and subscribers.)
>My plan for doing this is to create just two subscribers in NS - a
>"dummy" EmailChannel subscriber, and a "dummy" SMSChannel subscriber.
>Then, for a given event, my EventRule will query all of my custom
>subscribers and all of the custom fields that I need. For the
>Notifications view SubscriberID field: if the subscriber wants Email,
>I'll use the dummy EmailChannel user; if the subscriber wants SMS, I'll
>use the dummy SMSChannel subscriber.
>Do you think this is workable? Do you think that by "short-circuiting"
>NS's subscriptions/subscriber management that I'll lose out (e.g. but
>losing traceablity of the SubscriberID in logs/report or in some other
>Thanks in advance,