If you're using 2005, there are some new views that allow you to
create subscribers, devices, and subscription data without going
through the API. So you could create a connection to SQL Server and
issue something like:
INSERT INTO NSInstance.NSSubscriberView (SubscriberId, Enabled)
VALUES (N'[email protected]', 1)
You could create a transaction object to handle that aspect of it.
If you're using SQL Server NS 2000, then your options are more
limited. You could use the API to create the the subscriber, device,
and subscriptions and at the conclusion check to make sure everything
was created appropriately. If not back out.
This scenario doesn't handle a crashed SQL Server, so you'd probably
want to implement some kind of periodic checking of the subscriptions
- a scheduled task to kick off periodically to make sure each
subscriber has a subscription for each device. Not perfect, but
probably as close as you can get without either 2005 or going through
SQL Server MVP
Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On Fri, 19 Aug 2005 16:01:32 -0400, "Wayne"
<[email protected]> wrote:
>Suggestions on how to role my own with the API? I know I could access the
>Stored procedures directly, but would like to refrain from that, and
>I'm not clear on how to get at the database connection that the API uses
>"Joe Webb" <[email protected]> wrote in message
>> Wayne -
>> As Kate mentioned in another post, a custom delivery protocol may
>> address your delivery issues.
>> As for transactional support for the NS API, you're right it's not
>> built in. But you can always roll your own if need be.
>> Joe Webb
>> SQL Server MVP
>> Get up to speed quickly with SQLNS
>> I support PASS, the Professional Association for SQL Server.
>> On Thu, 18 Aug 2005 07:42:24 -0400, "Wayne"
>> <[email protected]> wrote:
>>>We have a need to send events out to multiple devices for a single
>>>subscription, the user may be able to decide what devices with what
>>>subscriptions. So far we have the following two ideas for accomplishing
>>>create a multiple subscriptions, one for each device the user wants the
>>>events to go to
>>>create a multiple unique device entries for each subscription
>>>So far as I've been able to tell there is no transaction support when
>>>the notification services API, so having to update multiple records for a
>>>single subscription can lead to further maintenance issues if the updating
>>>were to fail part way through.
>>>Is there a simpler way to have events for a single subscription to go out