Migration script fires 'The data definition language (DDL) command cannot be executed at the Subscriber' Yesterday I had run a migration script, produced by Visual Studio 2008 schema compare option, on a SQL Server 2008 database. It had run correctly.

But today, when I executed the same script, it threw a wierd exception in SQL Server:

Altering dbo.YourTableHere...

Msg 21531, Level 16, State 1, Procedure sp_MSmerge_altertable, Line 367
The data definition language (DDL) command cannot be executed at the Subscriber. DDL commands can only be executed at the Publisher. In a republishing hierarchy, DDL commands can only be executed at the root Publisher, not at any of the republishing Subscribers.
Msg 21530, Level 16, State 1, Procedure sp_MSmerge_ddldispatcher, Line 191
The schema change failed during execution of an internal replication procedure. For corrective action, see the other error messages that accompany this error message.
Msg 3609, Level 16, State 2, Line 1
The transaction ended in the trigger. The batch has been aborted.


The statement which threw the problem is:

PRINT N'Altering dbo.YourTableHere...';
GO 
ALTER TABLE [dbo].[YourTableHere]
         ADD [a_new_timestamp] TIMESTAMP NOT NULL;


Is there anything I can configure to make my script run correctly without these warnings?

The computer I am running this script is acting as subscriber and it has a Replication that should be deleted?
We found traces of a replication that had been activated in the past in a specific table.

Replication was not fully removed from this table. 

We also notice that the script works in different database name (a database with the same structure). 

Here is the history:


We restored database from DATABASE_A (with traces of replacation) to DATABASE_B
We run the stript on DATABASE_B and it works
We run the script on DATABASE_A and it fails


Our DBA found traces of replication in DATABASE_A and in order to clean up the replication traces, he had run: 

sp_removedbreplication 'DATABASE_A'


I am not sure if there is something configured on system tables in SQL Server that are related to the name DATABASE_A. We are going to investigate this issue deeper to find dependencies or what is causing the error.