we see that SQL Server Object Explorer has a logical view of that same
table and also its columns and primary key.
SQL Server Object Explorer can also be used to launch the refactoring operations that I discussed earlier. You can’t do so from Solution
Through using SSDT and its predecessors over a number of years, I’ve
learned many of their nuances. Based on those experiences, here are
a few tips that I recommend you follow.
I mentioned earlier how on my current project we’re successfully
using SSDT to deploy to our production environment. I should also
point out that we first test those deployments against a backup of that
production environment. You should do the same.
SSDT includes a tool called SQL Compare that I haven’t covered
here. Many people use SQL Compare to produce scripts that they can
use to deploy changes made in their SSDT projects to their test and
production environments. That works OK, but it isn’t a mechanism
that I ever choose to use, for these reasons:
• SQL Compare is a graphical tool within Visual Studio. Thus, if
you want to use it in a production environment, you’ll have to
install Visual Studio over there—which generally isn’t a good
idea. Headless deployments (i.e., deployments done with a GUI)
are generally preferred in a production environment. You can do
so via an SSDT publish operation using the SqlPackage.exe tool.
• SQL Compare only compares schema and doesn’t make any provision for deploying data. On the other hand, the SSDT publish
operation provides for deployment of data via SQL scripts, which
are called post-deployment scripts.
If you’re successfully using SQL Compare for your deployments, by
all means continue doing so, but bear in mind the points I’ve raised
sql server Pro / may 2013