Updated SQL Server Data Tools October 2013

Updated SQL Server Data Tools October 2013

  • Comments 29

The October 2013 release contains an updated installer that does not fail due to certificate validation of the chained MSIs.  This release also contains a code change that will allow graceful handling of SQL Server 2014 CTP2 connections where not supported. 

Get it here: http://msdn.microsoft.com/en-us/data/hh297027

 

Contact Us

If you have any questions or feedback, please visit our forum or Microsoft Connect page
We look forward to hearing from you.

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • When will you be releasing a Visual Studio 2013 version?

    --Brendan

  • We are part of Visual Studio 2013 Professional, Premium, Ultimate, and also available in the express SKUs: Visual Studio Express 2013 for Web and Express 2013 for Windows Desktop.  Starting in VS2013, we will not offer our own standalone installer.

  • Does this release fix the ambiguous reference problem referenced in the following link. This problem has forced our entire operation to stay on SSDT from December 2012 and we would really like to update. We have more than 300k objects in our database and December's SSDT crashes so often we are almost ready to give up on the product.

    sqlblog.com/.../june-2013-release-of-ssdt-contains-a-minor-bug-that-you-should-be-aware-of.aspx

  • Hi Mathew, yes, I just tried Jamie's simple example and it is fixed.  I did the following with no build errors:

    CREATE TABLE [dbo].[Table1]

    (

       [ID] INT NOT NULL PRIMARY KEY

    )

    go

    CREATE TABLE [dbo].[Table2]

    (

       [ID] INT NOT NULL PRIMARY KEY

    )

    go

    CREATE PROCEDURE [dbo].[Procedure1]

    AS

       SELECT t1.*

       FROM    Table1 t1

       INNER JOIN Table2 t2

           ON    t1.ID = t2.ID

       ORDER BY Id

  • Where are the download links for the ISOs for the VS2010 version of this update?

  • What about this error:  

    Error 363 SQL71567: Microsoft.Data.Tools.Schema.Sql.SchemaModel.SqlFilegroup cannot be specified on Microsoft.Data.Tools.Schema.Sql.SchemaModel.SqlTable when there is the clustered Microsoft.Data.Tools.Schema.Sql.SchemaModel.SqlPrimaryKeyConstraint on the table.

    We have over 100 instances of this in our projects which has broken our DB projects and made them unusable. Is there a fix or workaround for this?

  • @Jill, does this mean that the release cycle will be in line with VS2013 from now on ?

  • @Mark, We are just getting the ISOs for Dev10 propagated to download center and then will update the release page.  English and German should be available this morning.  

    @Ernesto, we will be pushing our updates through the VS Update for Visual Studio 2013 but are not tied only to their major updates.  If we have important bug fixes, we will still be able to release on our cadence through their channel.

    @molson83, I'll look at that today and reply back.

  • Jill,

    Thank you for monitoring this thread and taking the time to respond.

    I hope I am wrong and I am just missing something simple, but unfortunately it seems that the problem I and Jamie where describing is still there and still a HUGE issue. I agree that Jamie's test does now compile without error, but it is simply masking the real and deeper issue. That is that SSDT no longer interprets SQL the same way the SQL engine does and it makes the whole project nearly unusable. I can make educated guesses as to what has changed in the tokenizing order of the TSQL since the December release and as to why the use of the * in the select predicate now works, but let me post a small variation on Jamie's original post to illustrate how deep this problem really is.

    CREATE TABLE [dbo].[Table1]

    (   [ID] INT NOT NULL PRIMARY KEY)

    go

    CREATE TABLE [dbo].[Table2]

    (   [ID] INT NOT NULL PRIMARY KEY)

    go

    CREATE PROCEDURE [dbo].[Procedure1]

    AS

      SELECT

    t1.Id,

    t2.Id as ProductId

      FROM    Table1 t1

      left JOIN Table2 t2  ON    t1.ID = t2.ID

      ORDER BY Id

    This seems to fail in both SSDT VS2010 & 2012. I admit that this test is a bit contrived, but it is perfectly valid SQL and neither SQL 2012 or 2008 have an issue with it, yet newer SSDT builds throw errors.  To me it appears it isn't correctly taking the aliasing of the column into account or isn't correctly initialized the column list when all columns are not in the select clause . In fact I can solve the problem by aliasing the original column name with the column name. i.e.

    CREATE PROCEDURE [dbo].[Procedure1]

    AS

      SELECT

    t1.Id as Id,

    t2.Id as ProductId

      FROM    Table1 t1

      left JOIN Table2 t2  ON    t1.ID = t2.ID

      ORDER BY Id

    will work, but I shouldn't have to do this.

    If I where to slightly rework this to present a more real world case I might use a NVARCHAR as a label field that would be in multiple tables. This is more like the real world situations and is standard when tables are automatically generated to support common business objects.

    CREATE TABLE [dbo].[Table1]

    (

      [ID] INT NOT NULL PRIMARY KEY,

      [Label] nvarchar(255) NOT NULL

    )

    go

    CREATE TABLE [dbo].[Table2]

    (

      [ID] INT NOT NULL PRIMARY KEY,

      [Label] nvarchar(255) NOT NULL

    )

    go

    CREATE PROCEDURE [dbo].[Procedure1]

    AS

      SELECT

    t1.Label,

    t2.Label as Organization_Label

      FROM    Table1 t1

      left JOIN Table2 t2  ON    t1.ID = t2.ID

      ORDER BY Label

    Again the error shows up just as it does over two thousands time in our project, while the December SSDT has no issues with exactly the same SQL. I can't believe that this is just a limited problem as the pattern of not aliasing the primary table in the generated SQL is pretty standard.

    I guess early on with SSDT, I was under the impression it used the same SQL interpreter as the SQL server products and this situation could never arise, but I was either mistaken or something fundamental to SSDT has changed.

  • Jill,

    Thank you for monitoring this thread and taking the time to respond.

    I hope I am wrong and I am just missing something simple, but unfortunately it seems that the problem I and Jamie where describing is still there and still a HUGE issue. I agree that Jamie's test does now compile without error, but it is simply masking the real and deeper issue. That is that SSDT no longer interprets SQL the same way the SQL engine does and it makes the whole project nearly unusable. I can make educated guesses as to what has changed in the tokenizing order of the TSQL since the December release and as to why the use of the * in the select predicate now works, but let me post a small variation on Jamie's original post to illustrate how deep this problem really is.

    CREATE TABLE [dbo].[Table1]

    (   [ID] INT NOT NULL PRIMARY KEY)

    go

    CREATE TABLE [dbo].[Table2]

    (   [ID] INT NOT NULL PRIMARY KEY)

    go

    CREATE PROCEDURE [dbo].[Procedure1]

    AS

      SELECT

    t1.Id,

    t2.Id as ProductId

      FROM    Table1 t1

      left JOIN Table2 t2  ON    t1.ID = t2.ID

      ORDER BY Id

  • Hello. It was a pain to get it installed for a french user having an english VS2012 installed.

    It looks like your download page give a localized version of the ssdt installer base on the browser locales. But the french installer fails at startup, displaying a very poorly written message which I suppose means "you cannot install french ssdt on an english VS2012".

    I have found no other way than switching my whole system to english US, clearing cookies from browser, then dowloading again ssdt to get an english ssdt that I finally could install.

    Can you provide an easier way to choose which localization of ssdt we wish to download please ?

  • please include an iso image, we cannot use web setup.

  • Does this release fix the issue in SQLPackage.exe that DROPS all users in target database if they are not in source dacpac -  when using /p:IgnoreRoleMembership=True /p:DropRoleMembersNotInSource=False /p:DropPermissionsNotInSource=False /p:DropObjectsNotInSource=True?

    This is a major dealbreaker for using SSDT.

  • I'd like to second Luis' comment.  This is a huge security issue for us as well.  For Azure, it's fine, but for the in-house databases, this is a critical design flaw.

    -jon

  • @Jill Currently there are seemingly no SSDT tools in VS 2013 RC, is that correct? Will I be able to create SSRS projects etc in VS 2013 RTM?

    --Brendan

Page 1 of 2 (29 items) 12