Replication won't drop because of view based on replicated table

  • We have transactional replication as a push (A -> S, B -> S, C->S ), where ther are a series of views on S, based on multiple replicated tables from different sources (select from tables sourced from A, B, C). When I re-create replication from A -> S (we backup and restore from production to development servers, requiring us to drop and later create replication), it won't let me because it says that there are views dependent on those tables.

    Is there a way to define the view so that it's not looking to see if the tables it uses are there?

  • My guess is the VIEW is defined WITH SCHEMABINDING, meaning it has a link to the referenced table in the metadata and SQL Server ensures you cannot drop the underlying table until that VIEW is dropped or redefined without the SCHEMABINDING option.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • Hmmm. I thought we had removed all WITH SCHEMABINDING all, but found two that didn't have it. Thanks.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply