Why can't Sql Server Data Tools understand Drop statements when importing scripts?

Question

I'm currently loading up a new sqlproj with custom scripts that were generated with RedGate SqlCompare during the course of a project as we adopt SSDT. However I find, rather annoyingly, that SSDT spits quite a lot of stuff into the ScriptsIgnoredOnImport file.

There seem to be some workarounds to help SSDT with its work. For instance, removing the boilerplate transaction stuff RedGate puts in seems to help it sort through the script. In the case of stored procs, it seems that changing all ALTER PROCEDURE commands to CREATE PROCEDURE causes SSDT to check out the old file and overwrite it with the new one, which is what I want.

However, for anything involving a DROP statement (tables, procedures; anything) I can't for the life of me get it to simply delete the file. And when it comes to cleanup of ~1000 objects, I can't consider anything that involves manual effort.

Therefore, for now I've resorted to tearing through the ScriptsIgnoredOnImport file with powershell and invoking tf delete on each line that matches a DROP PROCEDURE, but this is really a shoddy (not to mention painfully slow-running) solution.

I'd really much rather learn how to make SSDT delete things. Does it just simply not support deletion of objects through script import?

Answer 1

Have you tried doing a SQL Schema Compare from your database against the project? That should allow you to easily drop a bunch of objects. (Sadly, deleting objects through an import does not work. Nor do ALTER statements.) If this is a one-time task, I'd probably build a local database, run the Red-Gate script on it, then compare that against the SQL Project to create/update/delete objects. If this is ongoing, that will need a different solution, but this could at least get you started.