DDL changes explode the merge engine

You have to be extremely careful with the DDL scripts that you are executing if you are propagating schema changes through the merge engine. The gory details are all wrapped up out here: http://www.mssqlserver.com/replication/alert_merge_ddl.asp

You can view and vote on this issue which has been posted on Microsoft Connect at https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=299206

http://msdn2.microsoft.com/en-us/library/ms151870.aspx

"If the schema change references objects or constraints existing on the
Publisher but not on the Subscriber, the schema change will succeed on the
Publisher but will fail on the Subscriber."

In your particular case it fails as your publication the first thing that
the merge agent does is apply the schema changes and breaks.

Note further that Microsoft has add the following features.

1) the ability to cancel the schema changes with the following proc -
sp_markpendingschemachange
2) this "new option in SQL Server 2005 that allows you to upload changes
first and then reinit" has been around since SQL 2000.

In your case you will have to locate the row in
select *from sysmergeschemachange

and the delete it as follows, delete the offending row from

delete from sysmergeschemachange where schematext like '%fk_table2totable1%'

This will allow you to do the reinitialization. Note further that you don't
have to do the reinitialization, you can just remove this row and
replication will continue.|||

1. No, sp_markschemachange does NOT work in this case.

2. No. Deleting the row from the table does NOT work either, because it introduces a gap in the schemaversion sequence that creates problems in other areas of the engine. And doing direct modifications to the merge metadata is completely unsupported, so you had better have a support case open and do this under the direction of PSS