Working with SSDT in Offline Mode
A lot of power from SSDT comes in the offline
mode. This is where developers can create projects that are source-code
driven as opposed to database driven. To start, let’s create a project
based on our UsedCar database. Right-click the UsedCar database node in
the Server Explorer, and select, New Project to launch the Import
Database dialog shown in Figure 4.
Figure 4. Import Database dialog
Type UsedCar Project for the name, and
click the Start button. The dialog will go away for a minute and come
back with a summary pane of the objects it created. When you click
Finish, you can see that the Solution Explorer on the right-hand side
of the screen has the schema that defines our database. In fact, it has
.sql script files for all the objects including Bob and Bob User, our SQL login and database users, respectively.
Suppose we now want to add a column to the Inventory table to identify the asking price for the vehicle. To launch the table designer shown in Figure 5, you can double-click Inventory.sql in the Solution Explorer.
Figure 5. Table designer
The designer is interactive: to add a new
column, click an empty cell below car_year, and define the column name
and data type, for example, type car_askingpricemoney,
respectively. The TSQL that makes up the object is updated in real time
with what is in the grid. You can also update the table the other way
around: for example, change the TSQL statement in the bottom window
from “car_askingprice MONEY” to “car_askingprice SMALLMONEY”. Notice
the grid value changed as well. and
Click the Save button to save changes to the Inventory.sql file.
Suppose the developers made a lot of changes to
the schema and had no idea if the tables on production server were the
same as on their development server. One way they could check is to
compare schemas. To do so, right-click the UsedCar Project node in
Solution Explorer, and select Schema Compare. This will launch a dialog
asking you for the source and destination. For the source, leave it
pointed to the current project. For the destination, make a connection
to the local SQL Server instance and UsedCar database. When you click
OK, the comparison will be performed, and you will see our change in
the UI shown in Figure 6.
Figure 6. Schema Compare document window
From this UI, we can generate the T-SQL Script to make an update or issue the update immediately to sync both servers.
SSDT also supports refactoring. For example, if you want to change the name of a column of a table from CustomerID to Customer_ID,
it will look through every object in the application and tell you what
will be affected. It will then provide the update script needed to make
those corrections.
Application Versioning
If we dive a bit deeper into the pain points of
developing a database application, we can see that a database is
challenging to code and master. Developers have to maintain script
libraries for the application. These scripts do things like initialize
database objects, update schemas, and other things to mitigate the fact
that a database is stateful. Think of the scenario where a developer
updates an application. The database targeted by the application is
still the same database that existed before the update, so it now needs
to be updated to accommodate the changes to the application. Since
there is no versioning within SQL Server, it’s hard to tell for which
version of the application the database is configured. The update
scripts the developer writes are complex and critical to the success of
the application, so once the new application is deployed, the DBA has
to inspect these scripts to ensure they conform to the server instance
that the application is deployed to. As you can see from this example,
there are a lot of moving parts and issues to consider when developing
a database application.
With SSDT, you can build a dacpac file out of the project to help with versioning. For our example, let’s build a dacpac
file of the UsedCar project and deploy to our server. To start,
right-click the UsedCar Project, and select Properties. In the “Output
types” group box, check the “Data-tier application” check box, and
click Build. This will create the dacpac file in the output directory of your solution. At this point, you could go to SSMS and import the data-tier application.
Assume that we did connect to a SQL Server instance and deploy this dacpac package. If we made any updates to the solution, we can set a new version of the dacpac and deploy it again on the same instance of SQL Server. The existing database that is a part of the dacpac on the SQL Server would be upgraded to the new version.
