The new views are great for developing and testing; I don't see a
reason why you could not use them in a production environment, too. We
do still have the API so use whichever makes the most sense for what
If I'm developing a Subscription Management Application using ASP.NET,
I'll likely choose the API. If I'm creating new subscribers from a CRM
package, I'd likely choose the views.
SQL Server MVP
Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On 25 Jan 2006 05:36:21 -0800, [email protected] wrote:
>So basically, this improvement in subscription management via SQL is
>only really meant for development & testing. So if our data sits in
>another database, Microsoft doesn't want us triggering over to these
>views to add subscribers & subscriptions, right?
>Joe Webb wrote:
>> For v2.0, the *only* supported way to management subscription data is
>> via the API. There are lots of dynamically created views that cover
>> the base tables so accessing those tables directly or via sprocs is
>> not supported.
>> For 2005, we have been given the ability to use some view to
>> management subscriptions.
>> I've blogged about each of these scenarios here.
>> Creating Subscribers in v2.0
>> Creating Subscribers in 2005
>> Joe Webb
>> SQL Server MVP
>> Get up to speed quickly with SQLNS
>> I support PASS, the Professional Association for SQL Server.
>> On 24 Jan 2006 12:57:48 -0800, [email protected] wrote:
>> >I've read (or heard - can't remember) that we should use the API to
>> >handle subscription management. Why not just the Stored procedures?
>> >If we've got our data in other databases, why not just link to the NS
>> >server, and execute the SP to get the subscription data over?