Home of the Data Dude : tsbt-db

DefaultDataPath

gertd — Tue, 01 Dec 2009 01:48:10 GMT

VSDB uses the the ($DefaultDataPath) SQLCMD variable to represent the location where you would place your data and log file of your database. The deployment engine sets the value of SQLCMD variable by querying SQL Server using the following query: 1:...(read more)

DBSchema file for SQL LiteSpeed XP’s

gertd — Thu, 11 Jun 2009 03:10:38 GMT

Based on a customer request I created a .dbschema file which contains the definitions of all the extended stored procedures used by SQL LiteSpeed 5.0 that live inside the master database. Since schema import does not import the definition of extended...(read more)

Declarative Database Development

gertd — Sat, 06 Jun 2009 01:58:36 GMT

Define What You Want, Not How You Get There! If Not Exists… Database development is many aspects behind in comparison to regular application development. If you look how database development is integrated with regular application development or...(read more)

RTM of VSDB 2008 GDR R2

gertd — Wed, 22 Apr 2009 18:32:12 GMT

The QFE rollup release for the Visual Studio Team System 2008 Database Edition GDR release is now available. You can download the SETUP.EXE from the regular location. ( http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed...(read more)

FIX: Blank Unit Test Designer Problem

gertd — Wed, 11 Mar 2009 23:21:10 GMT

If you are running in to the following problem when creating unit tests when using database projects, there now is a fix! Consider the following scenario, you have you database project (.dbproj) open and requesting the creation of a Database Unit Test...(read more)

VSTSDB Blog Site

gertd — Tue, 24 Feb 2009 08:36:28 GMT

The Visual Studio Team System Database Edition team has created a new blog site to keep you informed and update about the latest developments.

Please check out: http://blogs.msdn.com/vstsdb

Thanks,
-GertD

DBProj.com

gertd — Fri, 20 Feb 2009 05:37:36 GMT

Some of you already know or noticed through sites like LinkedIn or Facebook that per the beginning of this month I started in a new role inside Microsoft. I moved in to an Software Architect role, working on the new Directory Services stack. Hence I needed a new place to publish my DataDude contributions to the community, this new place is DBProj.com

The goal of the site is very simple, provide as much as possible information about the “Visual Studio Team System 2008 Database Edition GDR” product. Yes, you are reading it correctly, the site will solely focus on the “GDR” release. When a next release will become available that builds on top of the GDR architecture, Visual Studio 2010, I will expand the scope to include that as well. Since it is no longer my primary job, I need to focus on something, I hope you understand.

Anyhow, from now on I will publish on the DBProj.com.

This is the end of a great 3-year journey, but that journey would not have been possible without the support of a great team of testers, program managers and developers.

Thank you all! This site is a contribution to your work and dedication!

Thanks,
-GertD forever a “DataDude”

Data Generator for SQL Server Sparse Columns

gertd — Fri, 06 Feb 2009 20:41:25 GMT

Genevieve, tester on the “DataDude” team, has created a new Data Generator which allows you to populate a random set of sparse columns through the use of an XML column set column. She posted it on the VS Code Gallery, http://code.msdn.microsoft.com/columnsetgenerator.

-GertD

PS: Dank je wel Genevieve!

Final Language Release of the GDR

gertd — Wed, 21 Jan 2009 01:47:38 GMT

Today we released the last language, Russian, of the planned localized versions of Visual Studio Team System 2008 Database Edition GDR. This brings the total count to 10 (including English). You can download the Russian edition of the GDR from the following location:

You can select the language of your choice from the general GDR download page:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

For completeness I included the complete list with the download locations:

Chinese (Simplified)

Chinese (Traditional, Taiwan)

English

French (fr-FR)

German

Spanish

Italian

Japanese

Korean

Russian:

-GertD

File Level Build Warning Suppression in the GDR

gertd — Sun, 11 Jan 2009 23:28:40 GMT

One of the small, but hard to discover new features in the GDR release is the ability to suppress warnings at the file level. Just to be very clear, this is suppression of build level warnings, not of static code analysis or deployment warnings!

Imagine you have a procedure that references a temp table that is created either dynamically or in some other procedure.

   1:  CREATE PROCEDURE [dbo].[Procedure1]

   2:  AS

   3:  BEGIN

   4:      SET NOCOUNT ON

5:

   6:      SELECT c1 FROM #t1

   7:  END

The system will raise a warning "TSD04151: Procedure: [dbo].[Procedure1] has an unresolved reference to object [#t1]."

You could always suppress build warnings at the project level using the "Suppress Warnings" option on the Build tab.

In the GDR you can also suppress warnings at the file level, using the Properties window. You have to select the file which contributes the warning in Solution Explorer. If the Properties window is not visible you can hit F4 or right click on the file name and select Properties. This will bring up the Properties window. This contains a file level option for suppressing build warnings. By providing the warning number, 4151, without the TSD prefix you suppress the "TSD04151: Procedure: [dbo].[Procedure1] has an unresolved reference to object [#t1]." for the procedure inside the file.

This little enhancement hopefully provides you with a more fine grain weapon against pesky warnings that otherwise would not go away.

-GertD

Two more languages released

gertd — Sat, 10 Jan 2009 01:57:25 GMT

Yesterday we released two more languages of the Visual Studio 2008 Team System Database Edition GDR release, Simplified Chinese and French in addition to the six languages we released on December 19th 2008.

Chinese (Simplified) (zh-CN)

http://download.microsoft.com/download/2/2/2/2223ECF9-7485-4A0B-8928-C881C876D261/Readme.mht
http://download.microsoft.com/download/2/2/2/2223ECF9-7485-4A0B-8928-C881C876D261/setup.exe

French (fr-FR)

http://download.microsoft.com/download/B/4/4/B44806AB-8176-4473-B2CC-887D52CCF895/Readme.mht
http://download.microsoft.com/download/B/4/4/B44806AB-8176-4473-B2CC-887D52CCF895/setup.exe

-GertD

Creating T-SQL Static Code Analysis Rules

gertd — Fri, 02 Jan 2009 01:41:13 GMT

One of the new features in the GDR release is that you can create your own T-SQL Static Code Analysis rules. This post will guide you through creating your first rule.

Step 1: Create a new Class Library project

Inside Visual Studio 2008 create a new "Class Library" project, you can use VB.NET or C#, however since I am VB.NET literate (sorry no offense) I will use C# for this example.

We will name the project "SqlRule".

Step 2: Add references

The next step is to add the required assembly references to the following assemblies:

Microsoft.Data.Schema
- %ProgramFiles%\Microsoft Visual Studio 9.0\VSTSDB\Deploy\Microsoft.Data.Schema.dll
Microsoft.Data.Schema.Sql
- %ProgramFiles%\Microsoft Visual Studio 9.0\VSTSDB\Deploy\Microsoft.Data.Schema.Sql.dll

The Microsoft.Data.Schema assembly contains the core infrastructure, while the Microsoft.Data.Schema.Sql companion contains the SQL Server specific code

Step 3: Sign the assembly

In order to be able to place the assembly in the GAC, you first need to sign it. In the project properties, go to the Signing tab and create a Strong Name Key file named SqlRule (use a password of your choice).

Step 4: Add Extensions.xml file to project

Add a new XML file to the project named: "SqlRule.Extensions.xml"

Step 5: Update Extensions.XML file content

In order to register the rule with the system, we need to create an XML file which follows the naming convention of assembly name.extensions.xml and is placed in the VSTSDB\Extensions directory.

This extensions .XML file contains the following XML:

<?xml version="1.0" encoding="utf-8"?>
<extensions assembly="" version="1" xmlns="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions Microsoft.Data.Schema.Extensions.xsd">

</extensions>

Make sure the XML file references the XML schema declared in the %ProgramFiles%\Microsoft Visual Studio 9.0\VSTSDB\Microsoft.Data.Schema.Extensions.xsd. Since the assembly will need to be registered in the GAC it needs to be signed, so make sure to add the correct PublicKeyToken information, which will depend on the key used to sign the assembly.

Step 6: Add post build events

Next step is to add three post build events to make sure that the assembly created is copied to the correct location and that the extension manager will pick it up and load accordingly.

Add the following post build steps:

copy "$(TargetDir)$(TargetName)$(TargetExt)" "$(ProgramFiles)\Microsoft Visual Studio 9.0\VSTSDB\Extensions\$(TargetName)$(TargetExt)" /y
copy "$(ProjectDir)$(TargetName).Extensions.xml" "$(ProgramFiles)\Microsoft Visual Studio 9.0\VSTSDB\Extensions\$(TargetName).Extensions.xml" /y
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe" /if "$(ProgramFiles)\Microsoft Visual Studio 9.0\VSTSDB\Extensions\$(TargetName)$(TargetExt)"

Inside the post-build event editor it should look like this:

Event 1 copies the generated assembly to the VSTSDB\Extensions directory; 2 copies the XML file that makes the extension known to the system and 3 registers the assembly containing the extension in the GAC (Global Assembly Cache).

Step 7: Implement the Rule class

Now that we are all setup, we will add a class to implement the rule. The project already contains a class, named Class1, so we will rename the class to UppercasedTableRule. For consistency sake you might want to rename the file name from Class1.cs to UppercaseTableRule.cs as well.

In step 7 we change will the class so at the end you have a template class from which you can start a new rules!

Step 7A: Add using statements

In order to use the be able to access the namespaces more easily add lines 6-13 to you class definition.

   1:  namespace SqlRule

   2:  {

   3:      using System;

   4:      using System.Collections.Generic;

5:

   6:      using Microsoft.Data.Schema.Extensibility;

   7:      using Microsoft.Data.Schema.SchemaModel;

   8:      using Microsoft.Data.Schema.SchemaModel.Abstract;

   9:      using Microsoft.Data.Schema.ScriptDom;

  10:      using Microsoft.Data.Schema.ScriptDom.Sql;

  11:      using Microsoft.Data.Schema.Sql.SchemaModel.SqlServer;

  12:      using Microsoft.Data.Schema.Sql.SqlDsp;

  13:      using Microsoft.Data.Schema.StaticCodeAnalysis;

14:

  15:      internal class UppercaseTableRule

  16:      {

  17:          public UppercaseTableRule()

  18:          {

  19:          }

  20:      }

  21:  }

Step 7B: Add provider support

The underlying architecture of the GDR has been changed to a provider based model, a feature extension like a T-SQL Static Code Analysis rule can express to the underlying extension manager which providers it supports. For example if you want to create a rule that only applies to SQL Server 2000 you can indicate this by using the following attribute:

[DatabaseSchemaProviderCompatibility(typeof(Sql80DatabaseSchemaProvider))]

If you want to indicate that the rule supports all SQL Server versions you can indicate this by using:

[DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

If you do not care you can simply indicate you support any provider by using:

[DatabaseSchemaProviderCompatibility(typeof(DatabaseSchemaProvider))]

The reason this works is because existence of the following inheritance relationship between these classes: Sql80DatabaseSchemaProvider (and Sql90DatabaseSchemaProvider and Sql100DatabaseSchemaProvider) inherit from SqlDatabaseSchemaProvider, which itself inherits from DatabaseSchemaProvider which implements the IExtension interface. This way the rule writer has full control in expression which versions are supported and not supported.

In our sample rule want to work with all SQL Server providers/versions so your code will look like this (see line 15):

   1:  namespace SqlRule

   2:  {

   3:      using System;

   4:      using System.Collections.Generic;

5:

   6:      using Microsoft.Data.Schema.Extensibility;

   7:      using Microsoft.Data.Schema.SchemaModel;

   8:      using Microsoft.Data.Schema.SchemaModel.Abstract;

   9:      using Microsoft.Data.Schema.ScriptDom;

  10:      using Microsoft.Data.Schema.ScriptDom.Sql;

  11:      using Microsoft.Data.Schema.Sql.SchemaModel.SqlServer;

  12:      using Microsoft.Data.Schema.Sql.SqlDsp;

  13:      using Microsoft.Data.Schema.StaticCodeAnalysis;

14:

  15:      [DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

  16:      internal class UppercaseTableRule : Rule

  17:      {

  18:          public UppercaseTableRule()

  19:          {

  20:          }

  21:      }

  22:  }

Step 7C: Inherit from base Rule class and add the constructor

Next step is to have your class inherit from the base Microsoft.Data.Schema.StaticCodeAnalysis.Rule class. See line 16.

The Rules base class implements the Microsoft.Data.Schema.Extensibility.IExtension interface which is used by the extension manager to identify loadable extensions.

After we inherited our class from the Rule base class, it is time to implement the constructor of our class. Since we inherit from rules we need to call one of the two constructors implemented in the base class as a result.

   1:  // Summary:

   2:  //     Initializes a new instance of the Microsoft.Data.Schema.StaticCodeAnalysis.Rule

   3:  //     class.

   4:  //

   5:  // Parameters:

   6:  //   idNamespace:

   7:  //     Specifies the namespace string of the rule

   8:  //

   9:  //   id:

  10:  //     Specifies a short string to uniquely identify the rule inside a namespace

  11:  //

  12:  //   name:

  13:  //     Specifies a string displayed to the user to identify the rule

  14:  //

  15:  //   description:

  16:  //     Specifies a more-detailed description for the rule

  17:  //

  18:  //   helpUrl:

  19:  //     Specifies the URL of a Web page that contains more information about the

  20:  //     rule

  21:  //

  22:  //   helpKeyword:

  23:  //     Specifies a help topic for the rule

  24:  protected Rule(string idNamespace, string id, string name, string description, string helpUrl, string helpKeyword);

Lines 18 - 25 show you how to pass on the information to the base class constructor, defining a unique ID within a namespace and providing a name for your rule. Each rule writer must pick their own unique idNamespace to separate out your rules with rules from others and Microsoft, this is your namespace that you should re-use. Within your namespace you must provide a unique id for each rule, to prevent collision inside the namespace. For this reason the idNamespace and id parts should never be localized and should remain stable cross languages. The description, helpUrl and helpKeyword parts are optional.

   1:  namespace SqlRule

   2:  {

   3:      using System;

   4:      using System.Collections.Generic;

5:

   6:      using Microsoft.Data.Schema.Extensibility;

   7:      using Microsoft.Data.Schema.SchemaModel;

   8:      using Microsoft.Data.Schema.SchemaModel.Abstract;

   9:      using Microsoft.Data.Schema.ScriptDom;

  10:      using Microsoft.Data.Schema.ScriptDom.Sql;

  11:      using Microsoft.Data.Schema.Sql.SchemaModel.SqlServer;

  12:      using Microsoft.Data.Schema.Sql.SqlDsp;

  13:      using Microsoft.Data.Schema.StaticCodeAnalysis;

14:

  15:      [DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

  16:      internal class UppercaseTableRule : Rule

  17:      {

  18:          public UppercaseTableRule()

  19:              : base(

  20:                  "SqlRule",                                  // idNamespace

  21:                  "SR0001",                                   // id

  22:                  "Check if all table names are uppercased",  // name

  23:                  "",                                         // description

  24:                  "",                                         // helpUrl

  25:                  "")                                         // helpKeyword

  26:          {

  27:          }

  28:      }

  29:  }

Now we are two steps away from being able to build and debug our rules basic framework. We need to implement two overrides in the base class, the IsSupported and Analyze methods. For now we will implement them by throwing a not implemented exception.

This is how our class looks after implementing the overrides:

   1:  namespace SqlRule

   2:  {

   3:      using System;

   4:      using System.Collections.Generic;

5:

   6:      using Microsoft.Data.Schema.Extensibility;

   7:      using Microsoft.Data.Schema.SchemaModel;

   8:      using Microsoft.Data.Schema.SchemaModel.Abstract;

   9:      using Microsoft.Data.Schema.ScriptDom;

  10:      using Microsoft.Data.Schema.ScriptDom.Sql;

  11:      using Microsoft.Data.Schema.Sql.SchemaModel.SqlServer;

  12:      using Microsoft.Data.Schema.Sql.SqlDsp;

  13:      using Microsoft.Data.Schema.StaticCodeAnalysis;

14:

  15:      [DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

  16:      internal class UppercaseTableRule : Rule

  17:      {

  18:          public UppercaseTableRule()

  19:              : base(

  20:                  "SqlRule",                                  // idNamespace

  21:                  "SR0001",                                   // id

  22:                  "Check if all table names are uppercased",  // name

  23:                  "",                                         // description

  24:                  "",                                         // helpUrl

  25:                  "")                                         // helpKeyword

  26:          {

  27:          }

28:

  29:          public override bool IsSupported(Microsoft.Data.Schema.SchemaModel.IModelElement element)

  30:          {

  31:              throw new NotImplementedException();

  32:          }

33:

  34:          public override IList<Problem> Analyze(Microsoft.Data.Schema.SchemaModel.IModelElement modelElement, RuleSetting ruleSetting, RuleExecutionContext context)

  35:          {

  36:              throw new NotImplementedException();

  37:          }

  38:      }

  39:  }

Before we start making our rule implement something meaningful, lets check if we can build, deploy and debug our rule!

Step 8: Debugging a SQL Static Code Analysis rule

Before we start our debugging session, place 3 breakpoints, one on the constructor (line 18), the IsSupported (line 29) and Analyze (line 34) methods.

Next we need to define the debug host, we are going to use Visual Studio to debug Visual Studio, in order to do this, go to the project properties and define the "Start Action" and point it to use an external program, using "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"

Now you can start debugging. This will start a second instance of the Visual Studio shell.

No breakpoints will fire until you open a Database Project (.dbproj) file. Assuming copy operation of the assembly and Extensions.xml file were copied correctly to the Extensions directory and the assembly was correctly registered in the GAC, the first breakpoint that will fire is during the load if the database project. At that point in time the extension manager will check if assemblies inside the Extensions folder, based on the information provided by the Extensions.xml files inside this directory.

Call Stack: Extension loader, loads the extension

     SqlRule.dll!SqlRule.UppercaseTableRule.UppercaseTableRule    C#
     [Native to Managed Transition]
     [Managed to Native Transition]
     mscorlib.dll!System.RuntimeType.CreateInstanceSlow
     mscorlib.dll!System.Activator.CreateInstance
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.Extensibility.ExtensionTypeLoader.InstantiateType<Microsoft.Data.Schema.StaticCodeAnalysis.Rule>
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.Extensibility.ExtensionTypeLoader.InstantiateExtension<Microsoft.Data.Schema.StaticCodeAnalysis.Rule>
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.Extensibility.ExtensionHandle<Microsoft.Data.Schema.StaticCodeAnalysis.Rule>.Instantiate
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.StaticCodeAnalysis.StaticCodeAnalysisEngine.LoadRules
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.StaticCodeAnalysis.StaticCodeAnalysisEngine.LoadRules
     Microsoft.Data.Schema.dll!Microsoft.Data.Schema.StaticCodeAnalysis.StaticCodeAnalysisEngine.LoadRules
     Microsoft.Data.Schema.Sql.dll!Microsoft.Data.Schema.Sql.SchemaModel.SqlServer.SqlSchemaModel.InitializeValidator
     Microsoft.Data.Schema.Sql.dll!Microsoft.Data.Schema.Sql.SchemaModel.SqlServer.Sql100SchemaModel.CommonConstruction
     Microsoft.Data.Schema.Sql.dll!Microsoft.Data.Schema.Sql.SchemaModel.SqlServer.Sql100SchemaModel.Sql100SchemaModel
     [Native to Managed Transition]

This is your first validation to make sure you extension is copied to the right location, registered in the GAC and that your Extensions.xml file is correct. If you not breakpoint fires in the constructor, you are not setup correctly. It makes no sense to continue in that case, you have to fix it first. One common problem I have had is when running on Vista or a later OS, is that you need to make sure the post build event copies the files correctly. If you get am access denied error in the post build event, try running the Visual Studio using the "Run as administrator" option.

Now that we can debug and validated that our rule is loaded by the extension manager, we can check the Code Analysis configuration property page (Data->Static Code Analysis->Configure).

If everything works as planned, your rule should show up. If not check your Extensions.xml file content, make sure your public key is correct and the naming of your assembly and class are correct.

So far we have only setup the system. This is a great point to save your work, if you want to use this as a template, for other rules you want to develop later. Now we will continue by implementing the to remaining functions the IsSupported() and Analyze() methods which contain the meat of the rule.

Step 9: Implement the IsSupported() method

The IsSupported() method is used to indicate if a element should be analyzed or not. In our case we simply have to test if the element is a table, we can do this by checking if the type of element is an ITable.

   1:  public override bool IsSupported(Microsoft.Data.Schema.SchemaModel.IModelElement element)

   2:  {

   3:          return (element is ITable);

   4:  }

Step 10: Implement the Analyze() method

The analyze method contains the actual rule implementation, here you have to evaluate whatever you want the rule the check for, if the rule fails, you return one or more probems, by returning an IList of Problem class instances.

Lets walk through the final version of our simple rule.

   1:  public override IList<Problem> Analyze(

   2:      Microsoft.Data.Schema.SchemaModel.IModelElement modelElement,

   3:      RuleSetting ruleSetting,

   4:      RuleExecutionContext context)

   5:  {

   6:      if (modelElement.Name == null)

   7:      {

   8:          return null;

   9:      }

10:

  11:      List<Problem> problems = new List<Problem>();

12:

  13:      IList<string> nameParts = modelElement.Name.Parts;

14:

  15:      // test if table name is uppercased

  16:      if (string.Compare(

  17:          nameParts[nameParts.Count - 1],

  18:          nameParts[nameParts.Count - 1].ToUpper(),

  19:          false) != 0)

  20:      {

  21:          string message = string.Format("Table name [{0}].[{1}] is not uppercased.",

  22:              nameParts[0],

  23:              nameParts[1]);

24:

  25:          Problem p = new Problem(this, message, (IModelElement)modelElement);

  26:          problems.Add(p);

  27:      }

28:

  29:      return problems;

  30:  }

Lines 6-9: check if the model element passed in to the rule analyzer is named. In our case we only fire the rule for ITable objects, and tables have to be named, but in case your are evaluating more objects, you can be handed an unnamed object.

Line 11: Create an list of problems to return, by returning an empty list you indicate the rule did not detect any violations of the rule

Line 13: Our rule needs to check if the name of the table is all uppercase, so we ask the element for its name parts. Since objects can have 1 to 3 name parts the Parts property returns an IList<string> with all the name parts.

Line 16-19: This is the actual test if the name is formatted according to the rules definition. We only want to test the table name, not the schema name, so we only are interested in the last name part.

Line 21-26: If the test fails, the name does not consist of all uppercase letters, we create an error message, pass the message together with the offending element to the constructor of the Problem class, and add the Problem instance to the problems list.

Line 29: When the rule is finished it returns the list of problems.

If you are creating a table name my_TABLE, executing the rule will result in the following output in the error list.

This brings us to the end, you have build you first T-SQL Static Code Analysis rule! You can download the sample project SqlRule_v1.zip from my SkyDrive.

I hope this sample helps you getting started writing your own rules.

-GertD

GDR VPC's

gertd — Thu, 25 Dec 2008 02:06:43 GMT

We just released a new set off VPC's for Visual Studio 2008 Team Suite (including TFS) which now have the Visual Studio 2008 Team System Database Edition GDR bits installed. These VPC's provide an easy way to test out the GDR release. There is a Virtual PC and Hyper-V based image.

For details check out Brian Randell his blog covering this announcement.

You can download the VPC from the following location:

VSTS “all-up” Virtual PC/Virtual Server image (6 GB download, expands to 15 GB)
VSTS “all-up” Hyper-V image (6 GB download, expands to 15 GB)

I want to thank Brian Randell for adding the GDR bits to this wonderful VPC!

-GertD

Handling of COMMENTS in the GDR

gertd — Sat, 20 Dec 2008 06:19:05 GMT

In the GDR you will mainly find large improvements, but it is not everything is better. One area where we regressed functionality is the deployment of comments inside T-SQL procedures, triggers, functions etc. With the move to a true and only model based system, objects that are stored in dbo.syscomments or sys.sql_modules, are modeled in such a way that we separate out body script from the object name and parameters. We do this for a reason, so we when you rename an object we also update the actual name inside the script body. The nasty side effect is that all comment before the first real statement in the script body and after the last real statement in the script body as lost when deployed.

For example see the following stored procedure which has a comment line on every possible line.

   1:  -- comment line 1

   2:  CREATE PROCEDURE [dbo].[p_Comments] -- comment line 2

   3:  -- comment line 3

   4:       @param1 int = 0, -- comment line 4

   5:       @param2 int      -- comment line 5

   6:  -- comment line 6

   7:  AS -- comment line 7

   8:  -- comment line 8

   9:  BEGIN -- comment line 9

  10:      SET NOCOUNT ON -- comment line 10

  11:      -- comment line 11

  12:      SELECT @param1, @param2 -- comment line 12

  13:      -- comment line 13

  14:      RETURN 0 -- comment line 14

  15:  END -- comment line 15

  16:  -- comment line 16

  17:  GO -- comment line 17

  18:  -- comment line 18

19:

If you would inspect how this information is stored inside the model, by looking at the .DBSCHEMA file which is produced by the build step, it looks somewhat like this:

   1:  <Element Type="ISql100Procedure" Name="[dbo].[p_Comments]">

   2:       <Property Name="IsAnsiNullsOn" Value="True" />

   3:            <Property Name="BodyScript">

   4:                 <Value><![CDATA[BEGIN -- comment line 9

   5:      SET NOCOUNT ON -- comment line 10

   6:      -- comment line 11

   7:      SELECT @param1, @param2 -- comment line 12

   8:      -- comment line 13

   9:      RETURN 0 -- comment line 14

  10:  END]]></Value>

  11:            </Property>

  12:            ...

  13:  </Element>

This fragment indicates that the script body starts at the first statement, in this case the BEGIN statement and ends at the END statements. Comments between those to statements are preserved when deploying, the others, comments line 1 through 8 and 15 through 18 did not make it over. Which become very apparent when you look at the deployment script.

   1:  PRINT N'Creating dbo.p_Comments...';

   2:  GO

3:

   4:  CREATE PROCEDURE [dbo].[p_Comments]

   5:  @param1 INT=0, @param2 INT

   6:  AS

   7:  BEGIN -- comment line 9

   8:      SET NOCOUNT ON -- comment line 10

   9:      -- comment line 11

  10:      SELECT @param1, @param2 -- comment line 12

  11:      -- comment line 13

  12:      RETURN 0 -- comment line 14

  13:  END

  14:  GO

The comments inside the source code are preserved, but they simply do not make it to the target.

The team is currently working on finding the appropriate resolution for this issue.

-GertD

GDR Language Releases

gertd — Sat, 20 Dec 2008 03:51:32 GMT

Today, we released 6 additional languages of the Visual Studio 2008 Team System Database Edition GDR!

Chinese (Traditional, Taiwan)

German

Spanish

Italian

Japanese

Korean

Additionally the GDR documentation has been translated into Japanese and is available via MSDN. There will be 3 more languages coming: Chinese Simplified, French and Russian.

Happy holidays,
-GertD