Don’t worry about the next two screenshots if you don’t check the Add to Subversion option when creating the new project.

Open Solution Explorer

From here you can develop a new project or tie this project into an existing environment, ie. import. If you choose to import and make changes, then hit F5 (or click Start) and the output frame will display the log and you will see a .dacpac file is created on your local project. That file can be ran on the remote server and changes will be applied.

Open solution explorer again, double click to open the object desired to change or create a new object by right click Add…

Make change, you can see I just added a new comment and hit F5 (Start). You will see the dacpac file created in the project path.

If you go to that folder it will contain a .sql file with the changes, the .dacpac can be extracted and the model.sql file will contain the imported schema (ie. previous version) before the intended changes.

You can also right click the project, hit Publish, the Output shows the dacpac gets build and you can publish to a desired target database connection as well as a data-tier application. Check out the checkbox Block publish when database has drifted from registered version. Pretty self-explanatory. Awesome!

In this initial debug demo I see the model.sql file has the headers of the objects stripped off so just FYI. I wouldn’t want to deploy this. It’s actually used for the schema compare to check if the target has any differences and block the deployment.

But the idea is that you can develop for a desired target and hand off the package to apply the changes.

This is a consolidated model of having to hand off multiple scripts. The .dacpac will contain the contents of the entire project, not just the changes.