I support an application that sits upon a SQL 2008 database and has an admin tool that allows app admins to do some field customization. This issues an ALTER TABLE command when saved, and since the app admin user has db_owner rights on the database, this would typically succeed. (Note this is a vendor app, so we can't change the internal behavior.)
The problem is that we are also using transactional replication to push some tables from this database to a (non-trivial) reporting environment, so ALTER TABLE commands are failing on these replicated tables.
This, in my experience, is expected behavior, so I recommended doing the "repl table shuffle" to apply changes (remove tables from replication, alter tables via app, re-insert tables, run snapshot job, monitor distribution job). This works and seems like the appropriate strategy for pushing changes into production, but for our dev environment seems overly DBA labor-intensive, especially for the amount of ongoing customization and testing the dev team has planned.
We've discussed whether snapshot replication would work any better for the dev environment, since the dev reporting environment doesn't have to stay immediately up-to-date, nightly push or "on-demand" is ok. Part of the testing cycle will be making sure that changes to the environment don't break existing reports.
So:
- If we switch to snapshot replication, will the ALTER TABLEs continue to fail, or will the snapshot simply take each table in its "current form" to push to the subscriber?
- Are there security changes, short of sysadmin, that I could give the app admin user that would allow these ALTERs to succeed, despite replication?
- Are there other, better better ways to support this without breaking either the vendor app, or the required replication to the reporting environment?
(Edit: We are replicating about 80GB of tables of a 2TB database, and the subscriber database contains other non-replicated mapping/reporting tables.)