Blog post detailing the release: https://blogs.msdn.com/b/ssdt/archive/2012/04/02/first-release-of-ssdt-power-tools.aspx

SSDT Power Tools installation location: https://visualstudiogallery.msdn.microsoft.com/9b0228c6-15d1-44de-9279-66dde12bf861?SRC=Featured

Please check it out,
@DataDude

Next week, at the SQL Server Connections conference, I will be presenting “Database Development with SQL Server Data Tools”, a 60 minute overview how you can leverage SQL Server Data Tools (SSDT) for your daily database development and deployment tasks.

When: Tuesday March 27th 2012, 10:00-11:00AM

Abstract:

Drop by if you are there!

@DataDude

Besides the final name there were other important data points shared at the PASS Summit regarding SSDT:

• SSDT will be broadly available as a free component of the SQL Server platform for all SQL Server users.
• SSDT targets: SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 and SQL Azure
• SSDT will update with releases of SQL Azure, which means every 4-6 months
• SSDT will be initially released with SQL Server 2012
• SSDT with SQL Server 2012 will be hosted in the Visual Studio 2010 SP1 shell. It will install standalone or combine with existing Visual Studio 2010 Professional SP1 or higher installations
• SSDT will also ship with the next major release of Visual Studio
• In the next major Visual Studio release, SSDT will replace and provide conversion capability for existing Visual Studio database projects
• You can preview this change in the Microsoft® Visual Studio® 11 Developer Preview which was released at the //Build conference in September 2011
• SSDT full versions and updates will be available online using the Web Platform Installer (WebPI)
• SSDT installation will provide an administrative install experience to create a sharable setup which can be placed on a USB thumb drive or internal file share behind your firewall

For more information, check out the slides from our PASS Summit breakout session Database Development with SQL Server Data Tools Code-Named “Project Juneau” [AD-213-M].

So when can you get it?

Well you have to wait till SQL Server 2012 is released. The good news is that you can check out CTP3 today and we will provide updated bits in Q4 of CY2011 for you to evaluate. Watch the SSDT MSDN forum and the team blog for more details in the coming weeks.

Thanks,
Gert Drapers (@DataDude)
Principal Group Program Manager
SQL Server Data Tools (#SQLDataTools)

https://msdn.microsoft.com/data/tools

This seems to be a common problem users are struggling with like illustrated by the following set of forum post. A user creates a database project, imports an existing database, builds and deploys. The resulting script always performs a CREATE DATABASE, why?

The answer is very simple, by default there is no target database connection defined, the deployment detects this and instead of failing, it assumes the target database therefore does not exist and creates a deployment script which will create the database.

Lets walk through the sequence of events:

1. Create a new database project, open the project properties and go to the Deploy tab
   
   
   
   As you can see the target connection is empty.
   
2. Import a database schema from an existing database. What most users expect, is when they import from an existing database, either as part of the New project izard or by using the “Import Database Objects and Settings…” option that the connection used will become the target connection, however this is not the case. The reason for this is because we do not want to incidentally override the database you import from. 
   
3. Build and deploy the database project. The last step is to build and deploy the project. When doing this using the default settings you will get presented the following output in the Output Window
   
   

   ------ Build started: Project: mydb, Configuration: Debug Any CPU ------   mydb -> d:\users\gert drapers\documents\visual studio 2010\Projects\mydb\sql\debug\mydb.dbschema ------ Deploy started: Project: mydb, Configuration: Debug Any CPU ------     Deployment script generated to: d:\users\gert drapers\documents\visual studio 2010\Projects\mydb\sql\debug\mydb.sql     The deployment script was generated, but was not deployed. You can change the deploy action on the Deploy tab of the project properties. ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== ========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

   
   
4. Switch the deploy action to: “Create a deployment scripts (.sql) and deploy to the database”. By default the “Deploy” action only creates a deployment script and does not deploy it to a database.
   
   
5. Now Deploy again and it will fail, but why?
   

   ------ Build started: Project: mydb, Configuration: Debug Any CPU ------     Loading project files...     Building the project model and resolving object interdependencies...     Validating the project model...     Writing model to mydb.dbschema...   mydb -> d:\users\gert drapers\documents\visual studio 2010\Projects\mydb\sql\debug\mydb.dbschema ------ Deploy started: Project: mydb, Configuration: Debug Any CPU ------ mydb.dbschema(0,0): Error TSD01234: Before you can deploy a database, you must specify a connection string in the project properties or at a command prompt.    Done executing task "SqlDeployTask" -- FAILED.   Done building target "DspDeploy" in project "mydb.dbproj" -- FAILED. Done executing task "CallTarget" -- FAILED. Done building target "DBDeploy" in project "mydb.dbproj" -- FAILED. Done building project "mydb.dbproj" -- FAILED. Build FAILED. ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== ========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========

   So somewhere hidden inside an error message  “Error TSD01234: Before you can deploy a database, you must specify a connection string in the project properties or at a command prompt.”, you will find that the connection string was not defined.

Summary:

• If you want a incremental deployment script, the deployment engine must be able to perform a comparison between the project and the target database, which is identified via the “Target connection” setting on the project Deploy tab.
• When you do not specify a target connection no errors nor warnings will get raised when the deployment engine only generates a deployment script which is the default setting.

I hope this dissolves one of the common VSDB pitfalls.

GertD @ DBProj.com

If you have any suggestions for topics please use the send email link on this blogs to pass on your suggestions. I hope you will find this useful.

GertD at DBPrioj.com

   1:  DECLARE @value nvarchar(512),

   2:          @rc    int;

   3:  EXEC    @rc = [master].[dbo].[xp_instance_regread] N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\MSSQLServer',N'DefaultData', @value output-- , 'no_output'; 

   4:  SELECT  @value AS [Value]

The problem is that this value by default is not getting populated when you install SQL Server! You have to set it using SQL Server Management Studio, using the Server properties dialog, on the Database Settings tab,  you will find the “Database default locations”.

You can programmatically set it using the following query:

   1:  EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData', REG_SZ, N'd:\dbs\MSSQL10.MSSQLSERVER\MSSQL\DATA'

This brings up the next question, what does VSDB return as the value if the DefaultData location Registry entry is not set? It returns the location of the master.mdf file. If you would turn on SQL tracing you will see the following query fly by:

   1:  DECLARE @filepath nvarchar(260),

   2:          @rc int

   3:   

   4:  EXEC master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\MSSQLServer',N'DefaultData', @filepath output, 'no_output' 

   5:   

   6:  IF ((@filepath IS NOT NULL) AND (CHARINDEX(N'\', @filepath, len(@filepath)) = 0))

   7:      SELECT     @filepath = @filepath + N'\'

   8:   

   9:  IF (@filepath IS NULL)

  10:      SELECT     @filepath = [sdf].[physical_name]

  11:      FROM       [master].[sys].[database_files] AS [sdf]

  12:      WHERE      [file_id] = 1

  13:   

  14:  SELECT @filepath AS FilePath

Now this still does not mean it works, because SQL Server or SQL Server Management Studio not validate if this location actually exists and is accessible from within SQL Server.

So the question becomes how can you protect yourself against this inside my deployment?

The following script can be helpful as a pre-deployment script to check if the $(DefaultDataPath) location actually exists and take action accordingly.

DataPathExistsCheck.sql

   1:  -- If we raise an error we want to stop execution of the deployment engine

   2:  :ON ERROR EXIT

   3:   

   4:  SET NOCOUNT ON

   5:  DECLARE @value nvarchar(512),

   6:          @rc    int;

   7:  EXEC    @rc = [master].[dbo].[xp_instance_regread] N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\MSSQLServer',N'DefaultData', @value output-- , 'no_output'; 

   8:  -- debug: shows the output

   9:  -- SELECT  @value AS [Value], @rc as [RC];

  10:   

  11:  DECLARE @result int

  12:  DECLARE @table as table(FileExists int, DirExist int, ParentDirExists int)

  13:  -- debug: shows the output

  14:  -- EXEC [master].[dbo].[xp_fileexist] @value

  15:  INSERT  @table EXEC [master].[dbo].[xp_fileexist] @value

  16:   

  17:  IF EXISTS (SELECT * FROM @table WHERE DirExist = 1)

  18:  BEGIN

  19:      PRINT ' DIRECTORY ' + @value + ' EXISTS'

  20:  END

  21:  ELSE

  22:  BEGIN

  23:      PRINT ' DIRECTORY ' + @value + ' DOES NOT EXIST'

  24:      RAISERROR('DIRECTORY DOES NOT EXIST', 16, 1)

  25:  END

  26:   

  27:  :ON ERROR IGNORE 

I hope this is helpful and builds a better understanding on how VSDB works under the covers,
GertD @ www.DBProj.com

First step, is to create a connection inside Solution Explorer, no problems here, I can create a connection, navigate the schema using Solution Explorer, use the table and query designer tools. Next step is to create a project. In this case I created a SQL Server 2008 Database project named sql2008r2.

Import Database Schema

The next step is to import a schema from the SQL Server 2008 R2 instance, using the Import Database Schema option, beforehand I created an instance of the good old Northwind database on the SQL Server 2008 R2 instance, named Northwind.

The problems start after hitting the Start option, or if you were using the new project wizard to create the project and import the schema in a single step, you would face the problem after hitting the Start button inside the wizard.

The problem manifests itself as follows:

The change in version number blocks the Import Database Schema code to connect to the SQL Server 2008 R2 instance, since it presents itself with a 10.50.yyyy instead of the 10.00.xxxx version number.

Schema Compare

Now we have an empty project, so lets attempt to use Schema Compare, and compare the SQL Server 2008 R2 database (as the source) with the project as the target.

This works great, not problems! You only need to make sure that you select all the object types you want to include. By default permissions and extended properties are excluded from the comparison and would therefore not get imported.

Deploy

Now we have a project, lets deploy it to a new database. In first instance this failed, because Schema Compare does not parameterize the file definitions of the database, so I had to update these, as shown below.

Updated file definitions:

   1:  ALTER DATABASE [$(DatabaseName)]

   2:      ADD FILE (NAME = [$(DatabaseName)_data], FILENAME = '$(DefaultDataPath)\$(DatabaseName).mdf', SIZE = 3328 KB, MAXSIZE = UNLIMITED, FILEGROWTH = 1024 KB) TO FILEGROUP [PRIMARY];

   3:   

   4:  ALTER DATABASE [$(DatabaseName)]

   5:      ADD LOG FILE (NAME = [$(DatabaseName)_log], FILENAME = '$(DefaultDataPath)\$(DatabaseName).ldf', SIZE = 832 KB, MAXSIZE = 2097152 MB, FILEGROWTH = 10 %);

   6:   

After this deploy and incremental deploy works as expected, without any problems. Next steps were to test Data Compare, Data Generation and Database Unit Testing, which all worked as expected as well.

So besides the glitch in Import Database Schema, SQL Server 2008 R2 and the VS 2008 Database Edition GDR R2 get along just fine, good to know.

GertD @ www.DBProj.com

The steps are pretty simple:

• Unload the project, by right clicking on the project node inside Solution Explorer and selecting the “Unload Project” option
• This will grey-out the project node inside Solution Explorer and mark it (unavailable). Now you can right click on it again and select the “Edit <your project file name>.dbproj” option. This will load the project file inside the XML editor.
• Next you have to add the target elements for the PreDeployEvent and PostDeployEvent, like below:

   1:  <Target Name="PreDeployEvent">

   2:      <Message Importance="high" Text="Pre deployment event"/>

   3:  </Target>

   4:   

   5:  <Target Name="PostDeployEvent" >

   6:      <Message Importance="high" Text="Post deployment event"/>

   7:  </Target>

• After you made all the changes, you save and close the project file and reload the project, by right clicking on the project node again and choosing the “Reload Project” option.
• If you forgot to close the editor, you will be asked if it can be closed and saved. Only after you confirmed this is OK, the project will be reloaded.
• Now you can test if your pre and post-deployment events are firing by deploying your project. If everything works you should see the pre and post build event messages in the output window like on lines 9 and 14.

   1:  ------ Build started: Project: nw, Configuration: Debug Any CPU ------

   2:      Loading project references...

   3:      Loading project files...

   4:      Building the project model and resolving object interdependencies...

   5:      Validating the project model...

   6:      Writing model to nw.dbschema...

   7:    nw -> D:\demo\nw\sql\debug\nw.dbschema

   8:  ------ Deploy started: Project: nw, Configuration: Debug Any CPU ------

   9:    Pre deployment event

  10:      Deployment script generated to:

  11:  D:\demo\nw\sql\debug\nw.sql

  12:   

  13:      The deployment script was generated, but was not deployed. You can change the deploy action on the Deploy tab of the project properties.

  14:    Post deployment event

  15:  ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

  16:  ========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

Now you should be able to hook-up your events to the pre and post deployment events. Please keep in mind that pre-deployment scripts do not change the outcome of deployments like discussed earlier in this blog post.

Success,
GertD @ DBProj.com

The above statements is something that most users do not realize when using pre-deployment scripts. Since the pre-deployment script is included in to the deployment script, it therefore by definition runs after the comparison the the source model with the target database (model), and therefore cannot change the behavior of the deployment.

For example:

If you know you have an orphaned object that is blocking a certain upgrade scenario,  most users expect that when you would drop the offending object in a pre-deployment script, that this would take care of things. However the deployment engine has already performed the comparison between the source model and the target database (model) and generated the deployment script based on the results.

In order to gain a better understanding about what is going on, lets step through the flow of activities inside the deployment engine.

1. The deployment engine takes as input the result of a build. It will de-serialize the source model (.dbschema) file to hydrate the source model representation in memory. It will take in to account the settings provided through the various configuration files, like Database.sqldeployment, Database.sqlsettings and Database.sqlcmdvars.
   
2. The second step is to create a target model representation, by importing the target database.
   Note: when the deployment engine detects that the target database does not exists, it will create a target model based on the model database, since SQL Server inherits all settings and objects inside the model database when creating a new database.
   
3. If a “Transaction.refactorlog” file is present, the refactorting operation will be applied to the models, by making changes to the target model to yield the correct outcome.
   
4. Then the two models are compared, in order to determine the differences between the source and target. Internally this results in to a set of all the differences, which are then represented in a tokenized format to represent each change, after which the tokenized stream of difference operations is ordered and optimized by folding/collapsing operations together. All this results in the actual deployment part of the script.
   
5. Once the previous step has been completed the single file deployment script representation is generated, which contains the following code blocks:
   
   1. The database code block contains the statements that either creates the database or checks if the database exists, based on the determination of the deployment engine.
   2. The pre-deployment code block, contains the consolidated code, by flattening all the include statements (:r filename) inside the pre-deployment master script file.
   3. The deployment code block is the code generated based on the model diff
   4. The post-deployment code block, contains the consolidated code, by flattening all the include statements (:r filename) inside the post-deployment master script file.
   5. The refactoring code block is maintaining the __RefactorLog table to indicate that a certain refactoring operation has been deployed to this instance.

Now that we better understand the order in which operations take place, we can conclude that “pre-deployment scripts can never change the outcome of a deployment”, and that we really need a pre-pre-deployment script that runs before the model comparison is taking place in order to influence the outcome of the comparison and therefore the outcome of the deployment engine.

GertD @ www.DBProj.com (aetk39ypwb)