Thanks for your detailed reply.
Re: Yes you should always quiesce the replication path before making changes to subscriptions.
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: You would not have to stop the rep agent when marking the table (if the "replication path" is quiesced)
So "quiescing the replication path" here includes a quiescing primary (active) database. Ok.
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.
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: When changes are made to subscriptions it will place a marker in the primary database
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: why you are not using a database repdef and database subscription for replication.
We've thought about this and it's a possibility someday.
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).
When we drop the rep_maint alias for a primary (active) db, it causes errors for db subscriptions (aka MSA replication).
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.
Ben