Mary-Jo Foley recently wrote a blog post about being better together. At Microsoft this is something we take seriously. In her blog post she includes some snippets of an interview with Donald Famer. Donald discussed how we exchanged some team members with the Excel team in order to have a great integration story. Anyone in management knows how important people are and will understand that moving people between teams is serious business.

So why do we do this? We do it because it creates the greatest value for our customers. Creating seamless experiences between products – built on open APIs - ensures customers get the greatest benefit out of their investments. it also means that end users (information workers as we like to call them) end up with the most natural level of interaction with the products without having to think much about it.

I’ll offer one proof point: I was recently talking with a friend of mine who’s at a large packaged food company. Mind you he’s in sales not in IT so he offers more of a business rather than technology perspective. They just started a pilot of SharePoint, Excel and PowerPivot. He couldn’t agree more with the value of better together. They initially started out looking at nonMicrosoft products and quickly realized the cost of employees learning another tool which didn’t naturally integrate into their daily route or with other tools would be too disruptive and costly to the business. This really hit home for me that the price on the box is only a small part of the overall equation. The productivity of your employees is far more important.

I've mentioned elsewhere that you should be thinking about a "data roadmap". A way of thinking about how you intend to leverage all of that data you're collecting.

And in that post I mentioned that Microsoft has a "roadmap" for SQL Server. We think about how to evolve the product all the time, with one overriding goal - to be the "Information Platform" for your organization. It's more than just storing and securing your data - it's about giving you tools that let you access that data from anywhere, quickly and safely. In SQL Server 2008 R2 you'll see big investments in this kind of thinking, from Master Data Services to Stream Insight and PowerPivot and even interaction with SQL Azure. We're giving you new ways to do the basic inputs and outputs, but we're also thinking beyond those operations to new ways of allowing you to provide that data to your organization. Bloomberg has a review on some of these features that you can check out here.

So make your data roadmap with our product roadmap in mind - it's not just data, it's information.

"Five" seems to be a big number these days - is it compression to have a "top-5" instead of a "top-ten"? :) Over at Network world they've posted a quick slide deck of "Five things we love about SQL Server R2". They even include...the Start Menu? OK - I guess everyone has different likes and dislikes. I think they're happy that we gave SQL Server 2008 R2 it's own menu area, rather than lumping it in with SQL Server 2008 (you're welcome). 

I agree with their first four for sure - and I'll throw in there things that you might not see as often, like being able to connect to SQL Azure from SQL Server Management Studio, increased database sizes in SQL Server Express, just to name a couple. By the way - if you haven't rushed over to check out the resources we have for you to learn the tech for SQL Server 2008 R2, what are you waiting for? They're free! Enjoy.

As announced a few weeks ago on the SQL Azure blog, SQL Azure now supports Data-tier Applications which are introduced with Visual Studio 2010 and SQL Server 2008 R2. Here’s a quick tour of the feature.

 Here’s what I did:

1. Launch Visual Studio 2010 and create a new Data-tier Application project
2. Import my pubs database from a local instance
3. Set my deployment properties to point to my SQL Azure account
4. Build and deploy from Visual Studio

It’s that simple!

So what does this look like? Here are some screen shots:

This is the New Project dialog in Visual Studio 2010. I select the Data-tier Application project.

Here’s a shot of the project after I imported the local database. I could have also created the database schema from scratch.

Here’s a shot of the deployment properties within the Data-tier Application project. The connection string is exactly the same as a local instance except the server name is my SQL Azure server.

I select build and deploy. Here are the results. The system built the DACPAC, connected to my SQL Azure instances, and deployed the Data-tier Application.

The new database, Pubs-Azure, appears in my SQL Azure admin dashboard.

Connecting SQL Server 2008 R2 Management Studio to my SQL Azure instance I see the databases as well as the meta-data for the Data-tier Application.

With Visual Studio 2010, SQL Server 2008 R2 Management Studio and the latest release of SQL Azure we have a symmetrical experience for creating, registering, and deploying Data-tier Applications. Unfortunately at this time we don’t support Upgrading a Data-tier Application on SQL Azure, as we do with an on-Premise install of SQL Server. To move to your database to the next version of your application you’d deploy side-by-side and migrate your data using your favorite data migration tool.

Try this out for yourself and I think you’ll find this to be extremely valuable. In addition, if you want to share your database schema with other people you no longer have to provide a bunch of Transact-SQL scripts. You can give them a DAC Pack file. The file will contain the name of the application, the version, and the database schema definition. This will make management of applications, including deployment much simpler!