Hands-On LabExploring SQL Server Data Tools for Visual Studio 2010 (RTM Update)Lab version: 1.2 (RTM Update)

Last updated: 5/16/2023

CONTENTS

OVERVIEW................................................................................................................................................. 3

EXERCISE 1: WORKING WITH CONNECTED TOOLS............................................................................5Task 1 – Connecting to SQL Server from within Visual Studio 2010.....................................................5

EXERCISE 2: CREATING A DATABASE PROJECT FROM AN EXISTING DATABASE......................11Task 1 – Creating a Database Project from an Existing Database......................................................11

EXERCISE 3: MODIFYING THE SCHEMA OF A DATABASE PROJECT..............................................13Task 1 – Adding a New Column to the Customer Table.....................................................................14

Task 2 – Adding a new View to the Database Model.........................................................................16

Task 4 – Refactoring to Meet Organizational Requirements.............................................................17

EXERCISE 4: DETECTING SCHEMA CHANGES...................................................................................19Task 1 – Detecting Schema Changes..................................................................................................19

EXERCISE 5: DEPLOYING A MODIFIED SCHEMA................................................................................22

EXERCISE 6: PREPARING A DATABASE TO MIGRATE TO SQL AZURE...........................................24Task 1 – Importing the Data-Tier Application if Needed....................................................................24

Task 2 – Importing and Retargeting the Project................................................................................25

SUMMARY................................................................................................................................................ 28

Overview

In this lab, you will learn how to develop database applications using SQL Server Data Tools (SSDT) for Visual Studio 2010. SSDT brings a powerful and modern development experience to applications targeting SQL Server or SQL Azure. The tools provide both connected and disconnected project models, and are designed to help to provide a one-stop-shop for developers by minimizing the number of external tools required to develop, test and debug applications.

Objectives

This lab is designed to teach the following skills

Using the SQL Server 2012 Data Tools for Visual Studio 2010

System Requirements

You must have the following items to complete this lab:

Microsoft SQL Server 2012

◦ Microsoft SQL Server Management Studio

Microsoft Visual Studio 2010

◦ Microsoft SQL Server Data Tools

SQL Server AdventureWorks for SQL Server 2012

◦ AdventureWorks2012 sample database

◦ AdventureWorksLT2012 sample database

Exercises

This Hands-On Lab comprises the following exercises:

1. Working with Connected Tools

2. Creating a Database Project from an Existing Database

3. Modifying the Schema of a Database Project

4. Detecting Schema Changes

5. Deploying a Modified Schema

6. Preparing a Database to Migrate to SQL Azure

Estimated time to complete this lab: 45 minutes.

Feedback

Your feedback is welcome! Please, post it on our UserVoice forums.

Exercise 1: Working with Connected Tools

Visual Studio 2010 provides the ability to connect directly to a database server, and to execute and analyze queries, in much the same way that these tasks can be performed from within SQL Server Management Tools. This provides developers with the ability to focus on a single tool while performing their work.

Task 1 – Connecting to SQL Server from within Visual Studio 2010

1. On the Start menu, click Start | All Programs | Microsoft Visual Studio 2010 | Microsoft Visual Studio 2010.

2. From the View menu, click SQL Server Object Explorer.

3. In SQL Server Object Explorer, right-click SQL Server and click Add SQL Server.

Figure 1Add SQL Server

4. Complete the Connect to Server window as shown below, and then click Connect.

Figure 2Connect to server dialog

5. Expand the KIWI | Databases | AdventureWorks2012 | Tables node and note that the experience is similar to the one provided by Object Explorer in SQL Server Management Studio.

Figure 3SQL Server Object explorer tree expanded

6. Right-click the AdventureWorks2012 node and click New Query.

Figure 4New query option in the contextual menu

7. In the query window, hover over each of the toolbar items to note their functions.

Figure 5Query Toolbar items

8. From the SQL menu, click Transact-SQL Editor, click Execution Settings, and then click Include Actual Execution Plan.

Figure 6Menu route to Include Actual Execution Plan option expanded

9. Type (don’t copy and paste) the following query in the query window and note how Intellisense assists with writing the query.

SQL

SELECT Color, COUNT(Color) AS ProductCount FROM Production.Product GROUP BY Color ORDER BY Color;

Figure 7Query type is IntelliSense assisted

10. Click the Execute Query toolbar button and note that the output is shown similar to the SQL Server Management Studio query output.

11. Click on the Execution Plan tab in the results pane and note that the execution plan has also been returned.

Figure 8Execution plan for the given query

12. In SQL Server Object Explorer, expand the AdventureWorks2012 database, and then expand the Tables node.

13. Right-click the dbo.ErrorLog table and click View Designer. Note the new table designer that has been provided in this version. Also note the T-SQL that represents the table design is shown as well as the graphical designer.

14. In the graphical table designer, check the Allow Nulls box for the UserName column and note that the T-SQL code is updated in synchronization. Uncheck the Allow Nulls box again.

Figure 9Transact SQL is updated in synchronization with designer changes

15. Also note the table structure summary that is provided in the upper right-hand side of the table designer:

Figure 10Table structure summary

16. Close the designer. When prompted to save changes, click No.

Figure 11Closing the editor

17. Close the query window without saving changes. (Leave SQL Server Object Explorer open for the next exercise).

Exercise 2: Creating a Database Project from an Existing Database

In this exercise, you will create a database project from an existing database. While it is possible to create a new database project from scratch, most database projects are created by taking existing application databases under control.

Task 1 – Creating a Database Project from an Existing Database

1. In SQL Server Object Explorer, navigate to the AdventureWorksLT2012 database, right-click and click Create New Project.

2. Configure the Import Database window as shown in the image below, and then click Start. (If prompted to save changes for any previous files, click No).

Figure 12Import database dialog

3. When the summary window appears, click Finish.

4. Note that after the import process finishes, a localdb instance has appeared in SQL Server Object Explorer.

Figure 13Localdb instance

5. In Solution Explorer, navigate through the dbo and SalesLT schemas and note the list of tables within the SalesLT schema.

Figure 14Database table definition files

6. Note that individual tables are represented by .sql source code files.

Exercise 3: Modifying the Schema of a Database Project

In this exercise, you will make some required enhancements to the database project that you have created. Note that when you make the changes within the project environment, you are making changes

only to the project elements, not to the database, as you are not operating with an ongoing connection to the database.

Task 1 – Adding a New Column to the Customer Table

1. In Solution Explorer, right-click the Customer.sql node and click View Designer. Note that the offline mode of development uses the same table designer that we saw when using a connected mode of development.

2. Scroll down through the list of columns and add a new column at the end of the table as shown, with the IsRetailCustomer name, its Data Type column as bit, and the Allow Nulls option unchecked.

Figure 15New column added

3. Since the new column is being defined as not allowing NULL, we also need to ensure that a default value is provided for the column. Make sure that the new IsRetailCustomer column is selected and click the Properties window toolbar icon.

Figure 16Standard toolbar button to show Properties box

4. As most customers are retail customers, set the default value in the Properties window to 1.

Figure 17Default value property

5. Click anywhere in the T-SQL window, then note that the T-SQL code has again been updated to add the DEFAULT value. You can make changes in the graphical designer, the properties window, and/or the T-SQL window and those changes are automatically reflected in the other windows.

Figure 18Standard toolbar button

6. Click the Start Debugging toolbar icon (or hit the F5 key) to start the build process. After a short period, you should see the Deploy Succeeded message at the lower left-hand side of the Visual Studio screen, under the SQL Server Object Explorer window.

Figure 19Start debugging

Task 2 – Adding a new View to the Database Model

1. In Solution Explorer, expand the SalesLT schema, right-click the Views node, click Add, and then click View.

2. In the Add New Item window, set the name of the view to RetailCustomers then click Add.

Figure 20Adding a new view

3. Modify the code window as per the following query. Note how Intellisense works, even while working in the disconnected model.

Figure 21Adding a new view

4. From the File menu, click Save All.

Task 4 – Refactoring to Meet Organizational Requirements

1. From the SQL menu, click Static Code Analysis, and click Run.

2. Note that some warnings are returned. (These could be converted to errors by selecting options in the project properties if required). In the code window, note the blue squiggle under the * operator.

Figure 22Warnings are underlined with a curly blue line

3. Hover over the squiggle and note the tooltip that appears. Organizational requirements (and SQL Server product group advice) do not allow the use of the wildcard operator * in the definition of views and stored procedures. From the SQL menu, click Refactor, then Expand Wildcards. Click on the SELECT statement and note the preview that appears below, then click Apply.

Figure 23Expanding wildcards

4. Another organization requirement is that all columns are prefixed or qualified. From the SQL menu, click Refactor, and click Fully-qualify Names. Note that each of the refactoring provides the ability to preview changes before they are applied.

5. When the Preview Changes window appears, click Apply and note that columns are now qualified, including the column in the WHERE clause.

6. From the File menu, click Save All.

Exercise 4: Detecting Schema Changes

At this point, we might wish to get a list of changes that have been made to the database model. In this exercise, you will see how schema changes could be detected.

Task 1 – Detecting Schema Changes

1. From the SQL menu, click Schema Compare, and click New Schema Comparison.

2. In the Select Source dropdown, click Select Source.

3. In the Select Source Schema window, select Project. From the Project dropdown list, select AdventureWorksLT and then click OK.

Figure 24Comparing database schema

4. From the Select Target dropdown list, click Select Target.

5. In the Select Target Schema window, click New Connection.

6. In the Connection Properties window, configure as follows and click OK:

Figure 25Connection properties dialog

7. Ensure that the Select Target Schema window looks like the following and click OK:

Figure 26Selecting target schema

8. In the SqlSchemaCompare1 window, click Compare.

Figure 27Compare button

9. Navigate around the schema comparison window and note how the changes are displayed:

Figure 28Comparison results

10. Close the schema comparison window (without saving changes).

Exercise 5: Deploying a Modified Schema

In this exercise, we will create a deployment script that could be used to deploy the modified schema to the database.

1. In the Solution Explorer window, right-click the AdventureWorksLT project and click Publish.

2. In the Publish Database window, click Edit and configure the connection details as shown and click OK.

Figure 29Configuring connection properties

3. While we could deploy the changes directly, the more common scenario is that we need to script the changes, ready to hand off to the person responsible for the production system. In the Publish Database window, click Generate Script.

Figure 30Publishing a database

4. When the publication completes, read through the changes in the generated script file. Note that the system has generated the required ALTER scripts.

5. From the File menu, click Close Solution.

Exercise 6: Preparing a Database to Migrate to SQL Azure

In this exercise, we will see what is required to deploy an existing SQL Server 2012 database project to SQL Azure. We will import an existing database and retarget it for SQL Azure.

Task 1 – Importing the Data-Tier Application if Needed

1. In SQL Server Object Explorer, expand the KIWI server, expand the Management node and expand Data-tier Applications.

2. If the BranchManagement application has not been deployed, perform the following steps:

a. Go to Start | All Programs | Microsoft SQL Server 2012, and then click SQL Server Management Studio.

b. In the Connect to Server dialog, type KIWI for the Server Name, and click Connect.

c. In Object Explorer, right-click the Databases node and click Deploy Data-tier Application.

Figure 31Deploying data tie application

d. In the Introduction window, click Next.

e. In the Select Package window, click Browse, and go to the Source\Assets folder for this Lab.

f. Click the BranchManagement.dacpac file to select it, and then click Open.

g. Click Next.

h. In the Update Configuration window, click Next.

i. In the Summary window, click Next.

j. In the Deploy DAC window, click Finish.

Task 2 – Importing and Retargeting the Project

1. In Visual Studio 2010, in SQL Server Object Explorer, navigate to the BranchManagement database (under the Databases node), right-click the database and click Create New Project.

Figure 32New project on BranchManagement database

2. Configure the Import Database window as shown below, and then click Start. (If prompted to save changes for any previous files, click No).

Figure 33Create project / Import database dialog

3. When the Summary window appears, click Finish.

4. In Solution Explorer, right-click the BranchManagement project and click Properties.

5. In the Project Settings tab, change the Target Platform to SQL Azure.

Figure 34Selecting Azure platform

6. Note the option that is also provided to create a script file for a Data-tier Application.

7. From the File menu, click Save All.

8. From the Build menu, click Build Solution.

9. Ensure that the project builds correctly.

Figure 35Build succeeded

10. In the View menu, click Error List.

11. In the Error List window, if any features had been used that are not supported by SQL Azure, a list of the issues that need to be corrected would appear. In this case, there are none. SQL Azure now supports the majority of SQL Server 2012 objects.

Summary

In this lab, you have learned to use the SQL Server Data Tools for Microsoft Visual Studio 2010. You have seen how to use the tools both in a connected and a disconnected mode, seen how to make schema changes using the new table editor, and also seen how to retarget a project for use with SQL Azure.