We have a project that uses ef-migrations containing multiple (read ~60) migrations created over a long period of development. Naturally, some of these
Just delete all the repetitions of this line:
DECLARE @var0 nvarchar(128)
Only the first declaration is sufficient. Your script will work smoothly! :)
After I experienced the problem first hand..
We decided to create smaller migrations. If the change was big enough that it required a GO command, then the developer was attempting to change too much in a migration. Unfortunately, the only way to control what goes into a migration is to comment out the changes.
I also pondered why I wanted the script so badly. Its not like I didn't trust EF to perform the migration correctly, (provided I tested it first). Ideally I would never and (thankfully) have yet to have a reason to modify it. I've only looked at it a few times when I started using EF Code First.
I don't like this answer, but I don't think it serves a purpose other than debugging a migration for Entity Framework Code First.
I put a Sql("--<GO>"); at the end of each migration. This runs OK as an applied migration and when I script the SQL I just do a find and replace on "--<GO>" to "GO". A bit manual but works for me. You could put Sql("--<GO>"); around your create trigger statements.
As per msdn
"GO is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql utilities and SQL Server Management Studio Code editor."
Since you are not using any of the above tools but SqlCommand class to execute your Sql statement Sql Server (and not EF - see the stack trace where the exception originated) is choking on it