Introducing Microsoft SQL Server Developer Tools,Code-Named "Juneau": An Introduction to Doing Database Development in a Modern Way

Few more questions:

1. Will this support\ship with all SKUs of the SQL versions noted, that is Standard, Developer, Enterprise, and EXPRESS (especially interested in EXPRESS)?
2. This was sort of addressed in Q/A at end of session, but other than the designers (for example table designers), "connected" querying, publishing to DAC, can we outline the differences between this and the current version of the Visual Studio Tools (Data Dude)? I assume the upgrade process from the Data Dude tools is straightforward, but is there really a compelling reason to upgrade? I assume yes, but is this the "END" of Data Dude?
3. +1 on handling of reference data. A "must have" feature for me.
4. Plans for test suites built around your UDFs and SPs?
5. I know in the begining of the talk it was clearly stated that this would not address the other "pillars" of SQL. Will SSRS have a project type supported by Visual Studio 2010 .slns? I don't believe my current SQL 2008 R2 targeted SSRS Report project (BIDS) will load in VS2010.

Good session

Hi @Brian

1. We are not yet ready to discuss the SKU support or pricing for SQL Server Developer Tools, Code-named "Juneau". Sorry. When we are ready, the details will be available via our MSDN site http://msdn.com/data/tools.aspx

2. You are correct to say that these tools are the natural descendents of the "Data Dude" tools in Visual Studio 2010 Premium and Ultimate editions. In our V1 offering, shipping with SQL Server "Denali", we will have a few notable missing items as enumerated on the later slides of the presentation, but many of these will be made available shortly after Visual Studio "vNext" ships.  Developers working in Visual Studio 2010 will have the option to convert their projects to work in the new project type as shown in this demo, or carry on working in the existing "Data Dude" bits.

3. Your comment is noted; this is a frequently-requested feature and we are considering it for a future release. Are there particular aspects of your reference data workflow you would like to see support for?

4. At present Database Unit Testing is one of the Data Dude features which will not arrive until post Visual Studio "vNext". Can you give some further detail of what you mean by "plans for Test Suites built around your UDFs and SPs" - what specific features are you looking for here? Feel free to drop me email at mwthomas at microsoft dot com, I would be happy to hear your feedback.

5. As mentioned in the beginning of the talk, in SQL Server "Denali" ' s next CTP in the summer, all the current "BIDS" components (SSIS, SSAS, SSRS) will be shipping on top of the Visual Studio 2010 shell alongside our Database Services bits. This means you will not need to use Visual Studio 2008 to open projects of these types any longer. In terms of deeper integration between the components (e.g. refactoring across database and reports for instance), this is being considered for future releases. Please let us know your most important integration points.

Thanks!

Mark Wilson-Thomas

Program Manager, SQL Server Developer Tools, Code-named "Juneau"

Great video, thanks!  Looking forward to using SSDT with VS (just what I as looking for).  Also, looking forward to the Visual Query Designer and the Database diagram tools are coming soon with SSDT.

This might be just the right tool. Looking forward to get started on it.

So am I correct that with Juneau, you don't need Team Foundation Server or Redgate's Sql Source Control?

Reference data - my comment is very late here.

I have used the 'synchronize' script pattern from Barclay's historical blog posts for reference data.

I think it's cruical that a reference data feature separate the data from the 'transform' T-SQL scripts that deal with inserting the data (possibly via a MERGE statement).

I would personally like to see an open/mergeable file for storing the reference data and a 'view code' feature that exposes the SQL scripts that back insertion on install or upgrade.

Bonus: you talk about database snapshots. It would be interesting to pair this feature with the snapshots concept so the database developer could see the table and its contents change over time/versions.