Mastering SSDT with the DataDude
This is your chance to hear the real story behind SSDT, directly from the man who built it. SQL Server Data Tools is effectively the 3rd version of the DataDude project, started in 2005 by Gert Drapers. SQL Server Data Tools (SSDT) lets you develop, test, and maintain SQL Server and SQL Azure databases offline on your desktop. SSDT's modern T-SQL development environment supports declarative model-driven development whether working connected or offline, and integrates with Visual Studio's project and application lifecycle management tools to enable team development and source code control support for SQL Server and SQL Azure databases.
This master class will get you started using SSDT; provides you with the architectural ins and outs of schema management using SSDT; team oriented database development and leveraging the command line and programmatic interfaces that accompany SSDT for importing, comparing and deploying database schemas. Learn it from the DataDude himself.
Developer-focused toolset for building SQL Server & SQL Azure databasesExperiences EnabledConnected DevelopmentProject Based DevelopmentApplication Lifecycle & ToolsFundamentalsDeclarative, model based database developmentIntegrated tools with modern language services Connected and offline with local testingTarget SQL Server and SQL AzureDetecting and managing database drift
SQL Server Object Explorer (SSOX)Modeled after SSMS object explorerModern T-SQL Coding Experience Buffered Declarative Object EditingModel-based with Error DetectionImperative Script ExecutionT-SQL IntelliSenseCode-behind Table DesignerView/Edit/Script Data (incl. copy/paste)Execute/Debug T-SQL Procedures, Functions
Database definition managed in a Visual Studio projectMulti-target SQL Server {2005, 2008, 2008R2, 2012, Azure}Advanced Language Services for T-SQLGo To Definition/Find All References/RefactoringF5 debugging with LocalDBVisualize schema differences and migrate changesPublish direct to database or via SQL script or DACPACIntegrated database drift detectionPoint-in-time SnapshotDrag & Drop import from SQL Server Object ExplorerApplication Lifecycle & ToolsMSBuild tasks for:BuildPublishT-SQL Static Code AnalysisMSBuild in a redist (SSDTBuildUtilities.msi)Database projects in build server environment (like Team Build) without installing full VS on build serverSSDT Integrates with all standard VS SCCS providersDACFX v3Schema ComparePublish
Publishing your Database ChangesTarget version aware:SQL Server 2005SQL Server 2008 & SQL Server 2008 R2SQL Server 2012SQL AzurePublish Direct, via SQL script, or DACPAC snapshots
DAC Framework v3.0 (DACFX)DAC FrameworkDACFX is the core SQL redist providing modeling, reverse engineering and deployment pipeline capabilitiesv3.0 supports the full domain of SQL Server 2005, 2008/R2, 2012, and SQL AzureManaged Public APIExposes verbs for DACPAC and BACPAC operationsCommand-line tool (SqlPackage.exe)Exposes DACPAC verbs, project publishDACUnpack.exeWindows file handler for unpacking DACPAC to diskDACFX ClientsSSMS, SSDT, SAMP, I&E, VS Web and DB Publishing
SQL Server Data Tools – SummaryDeveloper-focused toolset to author, debug and publish SQL Server & SQL Azure databasesSupports SQL PlatformFree, web updates for SQL Server and SQL Azure releasesWorks in concert with other SQL Server tooling (SAMP, SSMS)Compatible with your development environmentSupports Visual Studio 2010 & Visual Studio 11Migrates VS2010 database projects (*.dbproj)
Schema Compare is an incredibly useful tool, providing a visual head over SSDT’s model differencing and update engine. It can be used to compare any combination of database, project or dacpac, and allows selective update of the target schema (via an update script in the case of a dacpac). We’ve made some significant changes to the tool for the RTW release, improving its look and feel, particularly to make it easier to digest and process comparison results. This post describes many of Schema Compare's key features – some of which surfaced in CTP4 – with a screen shot at the bottom that highlights several of them.First, the visual comparison ‘language’ of the results grid:Differences-Only by Default: By default the grid contains differences only (with empty folders removed) – if there is only one difference you will see just one item. And the grid always contains all the actions resulting from the comparison – while you can hide an action temporarily within a contracted group it is always present in the grid and will apply to the update or script unless you exclude it by unchecking the action.Equal Objects filter:A toolbar button adds equal objects to the grid. Enabling this is useful if you want to review, for example, unchanged columns alongside the changed columns in a table. Unsupported Actions filter: You can also choose to see unsupported actions – these result from differences for which there is no supported action that can be taken on the target. These typically result from differences in server objects or built-in types between schema versions.Action Icons: Actions (Add, Change, and Delete) are visualized using icons, making it easier to absorb a set of changes at a glance. The checkbox alongside an icon indicates if the action will be included in the update or generated script. If there is no icon the item will not be included in an update or script.Grayed Items: Items that do not contribute to the update are grayed – excluded actions, unsupported actions and equal objects are all grayed. Folders are grayed when all their contents are grayed making it easy to see when a group of differences have all been excluded without you needing to drill in.Grouping: By default, items are grouped by action so you can quickly assess what changes will be made on update. You can also group the results by object type or by schema. You can expand or collapse a group to temporarily hide detail, and you can exclude all or include all objects in a group.Refactor Highlighting: Schema Compare processes the refactor log if present when targeting a database. Refactoring is indicated in the grid as a change action with the source name bolded to highlight the new schema and/or name. Refactoring will cause objects to be renamed in the database. Refactoring sometimes also shows up as a second order effect on other objects that SQL Server will modify when applying the rename. These will not be marked as actions in the grid as you cannot exclude them, but you will see the changed script if you select the affected object. Probably the biggest set of changes affects the script difference pane. While the grid provides a great overview, to see all changes to an object in the grid you have to fully expand it, which, can quickly clutter the view if you're reviewing many objects. To address this we’ve focused more attention on the script differencing experience – after all, you are writing and editing object scripts to begin with. Changes include:Expanded Object Scripts: The script difference pane now shows the combined scripts for an object and its hierarchical children. This gives a complete picture of all the changes affecting an object in one easy-to-scan place. To complement this, the Next and Previous buttons step between top-level objects only. Together, these two changes can dramatically simplify scanning through the results of a comparison. Enhanced Script Differencing: The script difference algorithm now treats child objects as discrete entities, more effectively highlighting those that have been added, deleted or changed. The color scheme is now more subtle and better reinforces the direction of changes. And remember that you can expand the script pane or swap it to the top – so you can easily optimize the layout to better focus on reviewing scripts.The screen shot below highlights many of these improvements.
SqlPackage: Command-line tool for creating and deploying SQL Server databases and DACPAC packages.Copyright (c) Microsoft Corporation. All rights reserved.Help for dynamic property usage./@<file>:<string> Read response file for more options./help:[True|False] (short form /?)Help for command actions./Action:{Extract|DeployReport|DriftReport|Publish|Script} Specifies the action to be performed. (short form /a)/OutputPath:<string> Specifies the file path where the output files are generated. (short form /op)/OverwriteFiles:[True|False] Specifies if sqlpackage.exe should overwrite existing files. Specifying false causes sqlpackage.exe to abort action if an existing file is encountered. Default value is True. (short form /of)/Profile:<string> Specifies the file path to a DAC Publish Profile. The profile defines a collection of properties and variables to use when generating outputs. (short form /pr)/Properties:{PropertyName}={Value} Specifies a name value pair for an action specific property; {PropertyName}={Value}. Refer to the help for a specific action to see that action's property names. Example: sqlpackage.exe /Action:Publish /?. (short form /p)/Quiet:[True|False] Specifies whether detailed feedback is suppressed. Defaults to False. (short form /q)/SourceConnectionString:<string> Specifies a valid SQL Server/Azure connection string to the source database. If this parameter is specified it shall be used exclusively of all other source parameters. (short form /scs)/SourceDatabaseName:<string> Defines the name of the source database. (short form /sdn)/SourceEncryptConnection:[True|False] Specifies if SQL encryption should be used for the source database connection. (short form /sec)/SourceFile:<string> Specifies a source file to be used as the source of action instead of a database. If this parameter is used, no other source parameter shall be valid. (short form /sf)/SourcePassword:<string> For SQL Server auth scenarios, defines the password to use to access the source database. (short form /sp)/SourceServerName:<string> Defines the name of the server hosting the source database. (short form /ssn)/SourceTimeout:<int> Specifies the timeout for establishing a connection to the source database in seconds. (short form /st)/SourceTrustServerCertificate:[True|False] Specifies whether to use SSL to encrypt the source database connection and bypass walking the certificate chain to validate trust. (short form /stsc)/SourceUser:<string> For SQL Server auth scenarios, defines the SQL Server user to use to access the source database. (short form /su)/TargetConnectionString:<string> Specifies a valid SQL Server/Azure connection string to the target database. If this parameter is specified it shall be used exclusively of all other target parameters. (short form /tcs)/TargetDatabaseName:<string> Specifies an override for the name of the database that is the target of sqlpackage.exe Action. (short form /tdn)/TargetEncryptConnection:[True|False] Specifies if SQL encryption should be used for the target database connection. (short form /tec)/TargetFile:<string> Specifies a target file (i.e., a .dacpac files) to be used as the target of action instead of a database. If this parameter is used, no other target parameter shall be valid. This parameter shall be invalid for actions that only support database targets. (short form /tf)/TargetPassword:<string> For SQL Server auth scenarios, defines the password to use to access the target database. (short form /tp)/TargetServerName:<string> Defines the name of the server hosting the target database. (short form /tsn)/TargetTimeout:<int> Specifies the timeout for establishing a connection to the target database in seconds. (short form /tt)/TargetTrustServerCertificate:[True|False] Specifies whether to use SSL to encrypt the target database connection and bypass walking the certificate chain to validate trust. (short form /ttsc)/TargetUser:<string> For SQL Server auth scenarios, defines the SQL Server user to use to access the target database. (short form /tu)/Variables:{PropertyName}={Value} Specifies a name value pair for an action specific variable; {VariableName}={Value}. The DACPAC file contains the list of valid SQLCMD variables. An error will result if a value is not provided for every variable. (short form /v)