However, this still doesn't solve the lack of transaction support with in
the API, and now I'll be going outside of the API to another table. Trying
to keep this all in sync will require use of the stored procedures and a sql
Any chance in the gold release of 2005 the connection can be exposed from
within the API so that it can be used to create transactions?
Enterprise Library Configuration Console Module Generator
"When a man sits with a pretty girl for an hour, it seems like a minute. But
let him sit on a hot stove for a minute and it's longer than any hour.
That's relativity." - Albert Einstein
"Joe Webb" <[email protected]> wrote in message
> Ah....Very nice solution! Thanks Shyam!
> Joe Webb
> SQL Server MVP
> Get up to speed quickly with SQLNS
> I support PASS, the Professional Association for SQL Server.
> On Tue, 23 Aug 2005 11:28:22 -0700, "Shyam Pather [MSFT]"
> <[email protected]> wrote:
>>This is actually quite simple to do. Remember that the match rule is just
>>join that produces the notification rows. Each row represents a
>>going to one device. So if you want to have the same notification sent to
>>multiple devices, you just need to write your match rule in such a way as
>>produce multiple rows with the same notification data, but different
>>names. Here's an example of one way to do it:
>>Keep a table that stores a mapping of subscriptions to devices. For
>>CREATE TABLE SubscriptionDeviceMappings
>> SubscriptionId bigint,
>> SubscriberId nvarchar(255),
>> DeviceName nvarchar(255)
>>In your match rule, you simply join like this:
>>FROM Events e, Subscriptions s
>> JOIN SubscriptionDeviceMappings m where m.SubscriptionId =
>>If the SubscriptionDeviceMappings table has multiple rows for each
>>SubscriptionId, you'll end up with multiple notification rows.
>>You'll have to maintain the SubscriptionDeviceMappings table in your
>>subscription management code, but that's really not different to keeping
>>device name in the subscription itself, which is a very common practice.
>>Hope this helps.