Introducing Redgate Data Tools in Visual Studio 2017

Play Introducing Redgate Data Tools in Visual Studio 2017
Sign in to queue


Redgate Data Tools are now included in Visual Studio 2017, allowing you to extend DevOps processes you already have in place for the application to SQL and Azure SQL databases too. In this demo and Q&A session, you'll see Redgate Data Tools in action to learn more about the challenges and rewards of Database DevOps and how they can increase your productivity when working with SQL.

Find out more details by visiting Redgate Data Tools page.



Session Type:

Live Session





The Discussion

  • User profile image

    This seems like a huge step backward. The "Numbered based Migrations" approach have all sorts of limitations that Database Projects solved. 
    In particular. 

    1. Ability to compensate for "drift" in Production systems. eg: Changes to production that didn't go thru the release process that cause the new release scripts to fail. (not supposed to happen in a rigorous DevOps shop, but does.)
    2. The inability to detect that some "migrations" make some older Migrations redundant. eg: Migration 10 adds a column, Migration 12 Indexes the column, Migration 31 drops the table as it is no longer required. (You still have to execute all of them even though only the last change is needed.)
    3. Using the query parser of a real instance of SQL Server to validate & generate the correct SQL for the SQL Target (Retail SQL or Azure DB)

    Don't get me wrong RedGate make some handy tools, but the "Migrations" pattern common in most ISV tools is vastly inferior & I'm concerned that MSFT might stop developing Database projects as the Dev Team incorrectly assume they have a new product that fits the DBA DevOps need. 


  • User profile image
    Step Backward

    Ditto. This looks tossed-in, clunky, and inferior.

  • User profile image

    @David_Lean: The reverse is true also.  "Numbered based Migrations" solves all sorts of limitations that SSDT Deployments doesn't handle. 

    Add a new NOT NULL column that must contain data not handled by a default.

    Split or combine tables.

    Reshape data as part of the deployment.

    With SSDT you don't know your deployment script until deployment.  This leads to all kinds of problems with DBA auditing potentially huge scripts that are unique to the environment.

    If you are getting drift in production, there are ways of detecting this on a continuous basis.  It's an operational problem, not something to deal with when you are releasing the next version.

    If you don't like it, don't use it.  But this tool provides the control not possible in the SSDT.

  • User profile image

    Same opinion here, I prefer SSDT concept over migrations concept, used it in the past with EntityFramework and after hundreds of migrations we started to have serious deployment problems we different client environments we need to upgrade.

    Also SSDT support some type of manual migration concept if needed for adding default data, just need to create scripts in a special folder, mark them not to be build and only copied, after that devops scripts can get those and run them along the same SSDT process using sqlpackage. 

    I have the same concern regarding future of SSDT since this colaboration with RedGate, does this mean developing new features to SSDT will be stopped? (e.g. adding initialization data)



  • User profile image

    @andreiga76: I'm curious.  How do you handle the examples I gave?

    > Add a new NOT NULL column that must contain data not handled by a default.

    > Split or combine tables.

    > Reshape data as part of the deployment.


Add Your 2 Cents