Gald to help... Please see my replys below.
Good to know, but I couldn't find this anywhere in the documentation when adding a new table to an existing publication/subscription. If this is a requirement, it really needs to be written down somewhere.
Re: This depends on the materialization method you are using to materialize data to the replicate database. If you review the SRS Administration Guide Vol 1 'Managing Subscriptions' section
They give a task list for each materialization method and step 2 and 3 are the important ones:
2. Suspend updates to the data in the primary database by stopping client applications that
generate transactions against the primary data directly or indirectly through Replication
Servers.
3. Quiesce the replication system components involved with replicating data from the
primary Replication Server to the replicate Replication Server.
Use admin quiesce_for_rsi at the primary and replicate Replication Servers and any
intermediate Replication Servers.
So "quiescing the replication path" here includes a quiescing primary (active) database. Ok.
Re: Yes
Again, the sp_setreptable man pages say nothing about stopping the rep_agent. The doc's do say to make sure the repdef exists first.
Re: Yes that is true however if you do mark the table first you will just get warnings that no repdef has been defined for the table.
A repserver 15.5 tech overview doc I have (dated 5/4/2010) talks about being able do alter repdef on the fly and the repserver will be able to keep track of which data is using which repdef.
Re: If you have this document I would need to see the document to review it to see what it is talking about.
Really? A subscription change in a downstream repserver will execute an rs_marker command in primary (er, "active") ASE server that's not even connected to the downstream repserver? Are you talking about alter repdef?
Re: Yes the marker helps check the complete path of replication from primary to replicate to validate the subscription.
We've thought about this and it's a possibility someday.
Re: Highly recommend looking into it and testing it.
One minor problem, for the rep_maint user that the DSI uses to run the actual insert/delete/update statements (non schema change commands), we alias rep_maint to dbo so we don't have to do lots of grants.
But we have to drop the rep_maint alias to db and add a real rep_maint user when running rs_init (it needs a real rep_maint user).
Re: How oftent do you run rs_init and for what purpose? Once the connection is created you should not have to run rs_init again?
When we drop the rep_maint alias for a primary (active) db, it causes errors for db subscriptions (aka MSA replication).
Re: What types of errors are you getting?
So I guess we have to figure out how to setup a rep_maint user in a db to have dbo privileges in that db without aliasing rep_maint to dbo.