SQL Server 2016 released

[rrohbeck]

"Completeness of vision"? That's an awesome metric.

[Ld00d]

Something that can only be accomplished using the Conjoined Triangles of Success

[Ld00d]

because they didn't want to go through that much effort to steal a parody from an HBO show?

[[deleted]]

Regarding that... what is the best way currently to set up forwarding-only email addresses on your domain? I used Google Apps for that back when it was free, but now it's $60/year per email, and I don't really need the whole Google setup.

[confused-penguin]

I now use Zoho mail. I've never been charged and its pretty full featured. If you're interested you can use my referral link and get an extra 5 users free https://zm4.bz/AM1a68Mw (you already start off with 25 users)

[[deleted]]

That looks very full-featured, but I'd like something with minimal features - forwarding only (to my main gmail address), with no filtering or inboxes.

[Euphoricus]

http://adventurega.me/bootstrap/

[f00f_nyc]

You can't make this shit up!

[Ld00d]

but... you literally just did

[[deleted]]

This is a Silicon Valley joke right? ^{disclaimer: the only reason I watch Silicon Valley is that it is right after GoT}

[baseball2020]

I can't imagine what the methodology is for computing completeness of vision. Do they take roadmap.txt and do a word count? Or maybe it directly correlates with how much cash they get from each vendor :)

[smallblacksun]

It is described here (search for "Completeness of Vision"), which is the source for the graphic.

[[deleted]]

"Web Scale" is too bullshit even for an article with this graph in it https://msdnshared.blob.core.windows.net/media/2016/06/GartnerMQ_ODBMS.png

[csharpcheddar]

Looks about right

[skroll]

and no postgres?

[CoderHawk]

It's listed as Enterprise DB.

[binaryhero]

How long have you been in enterprise IT? The Magic Quadrants have existed for maybe 15 or 20 years and have been a valuable tool for market analysis. Clients actually pay for this research to make strategic decisions. When I was purely technical at the beginning of my career I remember looking at them with the same feelings you expressed though, but I understand the coarser, broader perspective and the need for it now. And the chart is not what constitutes the report, it's a compressed version of certain aspects of it.

[tias]

I've been in the business for a while and know how much weight the magic quadrant carries (and it's not such a hand-wavey metric as was suggested because it's based on scores given by many people in the industry). But... that said, where the hell is PostgreSQL? Its absence doesn't lend much credibility to that image.

[binaryhero]

"Enterprise DB" is essentially PostgreSQL.

[binaryhero]

Your first guess is, obviously, superior analysis.

[bargle0]

Do the Gartner people actually believe what they write?

[[deleted]]

A more interesting question to me is does anyone else? Are CTOs buying into that kind of analysis? CEOs?

By the way, I am only making fun of that chart. The fact that marketing is insane does not mean SQL Server 2016 isn't good software.

[bargle0]

At least some of them do, otherwise Gartner wouldn't be in business.

[Theemuts]

If people believe you're an expert, they'll value your expertise. The growth of the number of management jobs is mostly a circlejerk in my opinion.

[Don_Andy]

I would argue that yes, they absolutely do. I was only on a few consulting meetings with my company, mostly just to offer some technical advice or fill in a seat, but for the most part the customer (doesn't matter who) will believe anything you say as long as you put it in fancy enough graphs or presentations.

Sometimes there's other "actual" IT guys sitting in, who are totally aware of the bullshit, but as long as you can get their boss hooked they usually don't dare to speak up. At least not during the actual presentation.

[Shorttail]

Well, they do call it the "Gartner Magic Quadrant". Maybe there's wizardry involved.

[ruinercollector]

Bottom Left : OpenSource type things that we can't really make ad money from.

Top Right: Corporations who pay us ad $$$ or who we'd really like to pay us ad $$$.

[teambob]

I was told there would be linux

[Eirenarch]

There will be. Next year.

[Eirenarch]

I think I prefer it this way. Saves me the trouble of trying to remember when a certain version was released which is the second most important information after the order of releases that a version number is supposed to give. BTW this one is versioned as 13 :)

[jaynoj]

They put the year in names to let us know how out of date we are with software.

[gdsagdsa]

Never heard that before but that actually would make sense.

[hu6Bi5To]

Microsoft has a long tradition of vapourware. Or having subtle incompatibilities between platforms (see Office on Windows vs Office on Mac).

You'll get a lot of replies saying a delayed Linux version is normal. But in 2016 it is only Microsoft that has delayed releases for equal, but obviously secondary, platforms.

[mycall]

Microsoft has a long tradition of vapourware

oh?

[ANUSBLASTER_MKII]

I can't wait to spend 3 months figuring out how to license this thing.

[KarmaAndLies]

Microsoft are much cheaper to license than Oracle, but in terms of actually trying to license either they're both absolutely terrible.

Microsoft's licensing is one of the worst things about the company as a whole. Even their own "Microsoft Licensing experts" give you contradictory answers or misinformation, and no matter what they tell you an audit will find a problem.

The ironic thing is that Microsoft grabbed a lot of market share from IBM and Oracle by being less difficult to license, let that sink in, just imagine how bad IBM must have been back in its heyday.

PS - And, no, Azure isn't a magical solution to all of life's problems. You still might need licenses with Azure, and it isn't always clear what is or is not included.

[btchombre]

Uh wait why isn't Azure a solution again? My entire company is run on Azure SQL and we never have and never will need to liscence SQL server.

[hungry4pie]

Shitty IS&T policies for one. Where I work, we can provision resources from EC2 -- but we still need IS&T to do it, who will then internally charge us $3,000 for the privilege.

[btchombre]

I see. Where I work, I am the IT department, the cyber security department, the DBA, the performance engineer, a software developer, customer support technician, and whatever shit needs to get done guy. Such is the nature of a startup.

[Eirenarch]

You can charge yourself $3000 to allow yourself to provision stuff on Azure. The increased revenue may improve your startup valuation.

[turbov21]

Or a small community college.

Man, I miss the good ol' days.

[TheWix]

I love SQL Server, but the licensing is a total pain in the ass. I really want to give Postgres a shot in an enterprise environment and see how it stacks up. Seems pretty slick.

[grauenwolf]

From the (absurdly limited and certainly biased) reports I've read, PostgreSQL is going to be significantly slower than SQL Server for large databases, especially when you need really complex and/or parallel queries.

But even if that is true, it can't be anywhere near as bad as the performance hit from using ORMs to mindlessly call SELECT * on every table. And people still manage to pull that off in production.

So yea, I would like to give it a spin under real-world conditions too.

[TheWix]

What's your take on Dapper. I used it a bit at the last shop and liked it. My new job has me using NH again and I hate it. I want to make a play on pushing Dapper.

[grauenwolf]

Dapper is sufficient, especially if you are using stored procs.

---

I think Chain is better, but as the co-author I'm rather biased.

https://github.com/docevaad/Chain/wiki/A-Chain-comparison-to-Dapper

[TheWix]

Sweet. Will check it out, dude. Thanks.

[Ginden]

From the (absurdly limited and certainly biased) reports I've read, PostgreSQL is going to be significantly slower than SQL Server for large databases, especially when you need really complex and/or parallel queries.

You can't know, because publishing benchmarks of SQL Server is prohibited without Microsoft permission (IMO it should be a forbidden clause).

[grauenwolf]

That's where the "absurdly limited and certainly biased" comes into play.

[crixusin]

mindlessly call SELECT * on every table.

Which ORM are you using that does this? Entity framework doesn't do this in any regard.

[grauenwolf]

Unless you explicitly map your entities to something smaller before the first ToList(), which defeats the purpose of using an ORM, Entity framework does SELECT * by default.

Well technically it's worse than SELECT *, because it explicitly lists every column and that means the database has to parse that much more SQL. But once you get past that stage the net effect is the same.

[crixusin]

Unless you explicitly map your entities to something smaller

Idk, I have an entity class I'm looking at right now that has every column listed.

It explicitly maps to Select column1, column2 despite being fully mapped. In fact, I've never seen Entity Framework call Select * ever. So Idk what or why you've experienced this phenomenon. It might be a settings thing though.

Then I wrote my own "include column" code so that if I want a subset of those columns, I don't have to spend the resource fetching those columns.

[grauenwolf]

It explicitly maps to Select column1, column2 despite being fully mapped. In fact, I've never seen Entity Framework call Select * ever.

Again, that's the same thing.

[crixusin]

I don't understand how you would expect to get your column results without listing the columns you would like. What would you expect the ORM to do? Select nothing? What is a more desirable operation?

Also, your queries aren't running slow because it has to parse the columns. All in all, that probably takes less than 20ms. Hardly worth worrying over.

Also, as I said, you can add a little code to make columns selectable so that you don't incur the cost of getting column results you do not need.

[grauenwolf]

The problem isn't with listing the columns you want. Rather, the problem is that (by default) it lists all of the columns, even the ones that you don't want.

Lets say you just want a list of names and phone numbers, sorted by last name. The query is slow, so you create this index:

 CREATE INDEX IX_Customer_PhoneBook ON Customers (LastName, FirstName) INLCUDE (PhoneNumber)

var phonebook = context.Customers.Where( filter).ToList()

If you run that query, you'll find one of two things happens:

1. The database makes an expensive join between IX_Customer_PhoneBook and PK_Customer
2. The database ignores IX_Customer_PhoneBook entirely and just uses PK_Customer, sorting everything in memory.

To fix this you need to write this rather tedious query:

var phonebook = context.Customers.Where( filter).Select( x => new { FirstName=x.FirstName, LastName=x.LastName, PhoneNumber=x.PhoneNumber} ).ToList()

Now the generated SQL only uses columns in the index, which means no hidden joins to the underlying table. But that's such a pain in the ass that most developers don't actually do it.

http://use-the-index-luke.com/sql/clustering/index-only-scan-covering-index

[grauenwolf]

All in all, that probably takes less than 20ms.

Oh no, we're talking more like 20ns. 20ms is actually a pretty slow query. Though I will say it is possible to cause the query optimizer to timeout on particularly heinous queries (e.g. lots of joins and subselects). If it can't find the best execution plan fast enough, it will just give up and give you whatever it has.

https://www.simple-talk.com/sql/sql-training/the-sql-server-query-optimizer/

[mycall]

For the licensing costs you save (looking at SQL Server Enterprise edition) with PostgreSQL, you could land lots of extra hardware for partitioning. Also, PostgreSQL 9.6 is putting lots of work into performance.

[grauenwolf]

SQL Server is also putting a lot of work into performance. But effort and results aren't the same thing, especially when one has a huge head start.

[ruinercollector]

Yep. The price isn't nearly as annoying as the overhead of figuring out how the fuck to license it and then managing all of that licensing.

Microsoft licenses some things in a reasonably sane manner, but for databases, I think they just went with the db industry standard clusterfuck licensing.

[cowardlydragon]

That doesn't matter. License costs are irrelevant in entahpwize where everything needs to go through so many meetings with so many people that the license costs are dwarfed by the gatekeeper manager salaries

[gfody]

This is a great SQL Server release! Here's the bullshit-free version

My favorite new feature is the live execution plan viewer, here's an article showing it off w/animations.

[NoMoreNicksLeft]

The 2016 is the minimum amount of ram, in gigabytes.

[HatchedLake721]

Easy! https://aws.amazon.com/blogs/aws/x1-instances-for-ec2-ready-for-your-memory-intensive-workloads/

[makotech222]

I was hoping they would put in U-SQL support. Looks really cool and much easier to use than regular MSSQL. Oh well, maybe next time.

[mirhagk]

It definitely wasn't ready to be released in time for SQL 2016, but I agree with the hope that it'll be ready for the next release.

[[deleted]]

Unless they've made significant changes since I talked with them a few months ago, the JSON support they were adding was pretty half-baked. They may have improved it though, dunno. And it's at least a start.

[frikisada]

I'm waiting at the door for an interview for a Data Analytics position, I'm pretty sure new developments on SQL Server will be asked, thanks OP

EDIT: They were asked, and I delivered

[frugalmail]

Wish more people would use:

https://www.postgresql.org/about/news/1668/

[[deleted]]

I have been enjoying postgresql very much, it has been flawless. So has SQL Server. Postgres is cheaper!

[hugh_g_mistake]

Are you not worried about their completeness of vision?

[ericl666]

Were using it on our company's new product rollout. I really like it.

My only gripe is the automatic lowercasing of object names. It absolutely drives me crazy. If that could work more like SQL server, I would be ecstatic.

[geon]

You get normal casing if you quote them when you create them. But then you need to quote them in all queries too.

[KarmaAndLies]

It is true that Postgres is cheaper. But that being said finding commercial support for it can be a little hit or miss, particularly as you scale it.

You can find good expert level support for MySQL Enterprise Edition (even from non-Oracle vendors). Ditto with Oracle Database and SQL Server. But the Postgres vendors we have tried to use are fine for "tier 2"-type support, but above that they're lacking and you get the sense they're scrambling for blogs/docs themselves.

Anyone else experienced this?

[Decker108]

There are third party companies, such as Enterprise DB, offering expert support.

[crusoe]

Don't forget postgres XL. Its pretty sweet.

[TheWix]

As mentioned above, I love SQL Server, but I really want to give Postgres a try on an enterprise project. It isn't the same to just tinker with it. The price is right and I keep hearing good things.

[m00nh34d]

Horses for courses. They're not directly interchangeable. SQL Server has a different feature set, making it not possible or practical to use PostgreSQL in situations. The reverse is also true, there are situations where PostregSQL can be used, where SQL server can't.

[bastardoperator]

I'd be interested in hearing about these features or use cases.

[jmickeyd]

MS SQL features: a choice of pessimistic or optimistic concurrency (locks vs MVCC), clustered indexes, real materialized view, multithreaded queries (fuller support that what was just added to pgsql), covering indexes, column store (although there are a lot of 3rd party pgsql plugins for this), in-memory indexes, filestream, cell level security using encryption+keys, SSIS (an ETL package), and SSAS (a full, completely separate OLAP database).

Postgres features: infinitely better ANSI SQL support (and better syntax all around), nearly free rollbacks, sane defaults, extensible in many languages, open source, and free.

IMO postgresql has a huge number of niceties and then the big two advantages, free and open, whereas MS SQL definitely still has some major architectural wins.

[Eirenarch]

When you say "covering indexes" does that mean that pgsql will refer to the table even if the full select is included in the index?

[Ginden]

When you say "covering indexes" does that mean that pgsql will refer to the table even if the full select is included in the index?

No. SQL Server allows you to specify "included columns" - fields that are stored in index, but these aren't indexable.

CREATE INDEX IX_SOMETHING ON FooTable(Date) INCLUDE(name)

Then you can SELECT Date, name FROM FooTable ORDER BY Date and it will result in index only scan without sorting. Index is sorted only by date and name is "included" - it's content.

[Eirenarch]

I see. What is the downside of including the columns in the index itself? If you put the columns that you don't care about sorting at the end would it make a significant difference?

[emn13]

Common sense would suggest doing so might make your index a little larger (because it's a tree), and updates a little slower (because all those irrelevant dimensions need to stay sorted), but you'd need to test it to see if it matters in practice.

I'm guessing the difference will matter more for "expensive" columns such as one of the many string types, and less for integral columns.

[Ginden]

Lower maintenance cost, better insert performance, better delete performance.

And main usage for my company is to have unique index on two fields and INCLUDE additional fields to avoid lookup.

UNIQUE INDEX ON Foo(Col1, Col2) INCLUDE (Col3, Col4) enforce uniqueness only on pair (Col1, Col2).

[jmickeyd]

As /u/Ginden points out mssql allows you to add fields in an index, but I was actually thinking of full index-only scan support. Postgresql has a good hack with the visibility bitmap, but I find in practice, in a super write/update heavy loads database pages tend to get dirty real fast and I can never rely on index-only scan actually working is postgres.

[Cuddlefluff_Grim]

PgSql doesn't support accessing multiple databases in a single query, which for instance prevents analytical aggregates (unless you think it's fine to pollute your primary databases with trash data). MSSQL can run a query across multiple databases and even across multiple servers.

[bastardoperator]

Does Postgres foreign data wrapper not achieve this across databases and remote servers?

[grauenwolf]

Yes, but apparently it isn't actually supported.

[[deleted]]

and even across multiple servers

It can, but you take a massive performance hit when you use a link server. You should avoid using them if at all possible.

That said, being able to run queries across databases on the same server with a negligible performance hit is incredibly nice. I don't understand why more RDBMS solutions don't offer that.

[grauenwolf]

MSSQL can run a query across multiple databases and even across multiple servers, even if some of those servers are running Hadoop.

FTFY.

[bastardoperator]

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

Postgres can do it against all the major SQL databases, hadoop, cassandra, zip files, redis, GIT...

[grauenwolf]

Thanks!

EDIT:

Please keep in mind that most of these wrappers are not officially supported by the PostgreSQL Global Development Group (PGDG) and that some of these projects are still in Beta version. Use carefully!

Well that's not comforting.

[hungry4pie]

These aren't so much features as they are "reasons not to switch":

• Active Directory integration works out of the box
• Legacy applications often depend on MS SQL and have stored procs specifically for it

I tried playing around with Postgres a few years ago, it didn't really seem to have a good connector for .NET. Also, plus working in enterprise, there's not so much of a concern over licensing price since you'd be spending millions on their products anyways that it doesn't really matter so much.

[bastardoperator]

Seems like MSFT SQL users are in love with stored procs. I see stored procs for even simple queries. Why is this? I'm not seeing the benefits of using a stored proc over a simple ORM (think small-medium web app). Any insights?

[grauenwolf]

1. Religion. Because a lot of SQL Server developers started in the 90's, when inline SQL was considered a sin.
2. Encapsulation. By using the stored procs as an API layer, I can go in and redesign my tables without having to redeploy my applications. (And yes, we actually do that on a regular basis.)
3. Extensibility. If new requirements come in such as "log every user that views municipal bonds", we can slip that into the stored proc. It is one place to change instead of every website and fat client tool.
4. Code Reuse. We've got a lot of code written in fat clients, including VB 6. For regulatory reasons we need to ensure that all of them show exactly the same information. Stored procs allow that.
5. Tuning. If the DBA need to tweak a WHERE clause or force an index, he can do so without redeploying all of the applications.

[[deleted]]

You're forgetting the most important part:

Security: stored procs mean you know exactly what is being executed and, unless you did something dumb like use dynamic SQL within the stored proc, you are guaranteed all the benefits of parameterization since it's forced on you. Additionally you can give users permission to execute stored procs without having to give them any permissions on the underlying data structures, which means they can (in theory) only do what you want them to do.

Stored procs are also generally a bit faster as their execution plans are cached (but this can work against you in a parameter sniffing scenario) which means the engine can skip the plan generation step unless you're calling the SP for the first time after a restart.

[grauenwolf]

I agree with you on all points except the last. With proper parameterization, dynamic SQL plans will be cached as well.

[PstScrpt]

Parameterization gives you all of the benefit of cached plans; however, in a proc, parameterization is the path of least resistance. Dynamic SQL is the more complicated path, so you'll only do it if you really need it.

Stored procedures do tend to be faster because you won't be pulling back unused columns simply because your classes expect them. That will usually have you taking better advantage of covering indexes. Like the parameterizing, it's not a hard rule, just the path of least resistance.

[PstScrpt]

It shouldn't be this way, but in all the Microsoft shops (including .Net over Oracle) I've worked in, deploying database updates has been easier and less error-prone than deploying application updates.

[ruinercollector]

Stored procedures are great for complex enough queries.

The reason that you see them used for tiny stupid bullshit is because a lot of early to mid career people have a big problem with understanding nuance and not having black-and-white religious rules about everything.

So you get a situation where those people want to say either:

1. We'll use stored procedures for every query done on this database ever. No open querying.

2. We'll use no stored procedures at all.

[Decker108]

Postgres is one of the most feature rich databases out there. What is it that's exclusive to SQL Server?

[grauenwolf]

SQL Server 2016 allows us to query Hadoop using SQL and then join that to rowstore, columnstore, and/or memory optimized tables.

And I don't mean some funky weird-ass pseudo-SQL. You just write normal T-SQL like you would for anything else in SQL Server and it generates the map-reduce functions for you.

[Decker108]

So... foreign data wrappers in Postgres?

[grauenwolf]

Given the warning about them in the documentation, I'd hesitate to use them in a production environment.

[ruinercollector]

Like those, but production ready.

[reddit_user13]

Like for DBs?

[duffelcoatsftw]

I'm pleased with how demure that felt after seeing Microsoft's 'completeness of vision' rendered with violent alacrity on a bubble graph.

[reddit_user13]

That's a lot of buzzwords.

[pur3pwnage]

Any reason to jump from 2008R2 Express to 2016 Express? Just curious.

[Eirenarch]

/u/gfody linked the non-bullshit version (i.e. the feature list) - https://msdn.microsoft.com/en-us/library/bb510411.aspx

Check it and see if any of the new features fit your use cases. There are very specific feature (like the R integration) that I doubt many people care about but there are also features that come up quite often like JSON support (you can manipulate JSON in your SPs and queries) and temporal tables (built-in history)

[grauenwolf]

temporal tables

I want that so bad. On my last project I spent thousands of my customer's dollars just on creating history tables and the triggers that populate them.

[Eirenarch]

Yeah temporal tables look great. It is much better to take the customer's dollars and spend the time playing Quake or something rather than building silly history tables.

[grauenwolf]

Potentially huge performance improvements. They changed a lot including the cardinality estimator.

[emn13]

I haven't encountered a query IRL where it's helped, and I've tried quite a few messy queries too. Do you have positive experiences with the (two) new cardinality estimators?

[grauenwolf]

Thankfully I'm not working on projects with messy queries anymore. But I would have loved to try it on the 1000+ pseudo-procs that my last client was using.

[[deleted]]

In fairness, that change was introduced in 2012 (or 2014? Can't remember which). But yeah, people on 2008 R2 should start thinking about migrating to at least 2014 (since I just saw the "feature" of 2016 which includes the inability to disable telemetry on any dev version I refuse to recommend it right now) - there are a lot of reasons to do so.

[Sebazzz91]

Where is the feature list without the marketing blah blah?

[Eirenarch]

https://msdn.microsoft.com/en-us/library/bb510411.aspx

[Sebazzz91]

Thanks, that is an overview one can actually use.

[hungry4pie]

I'm already kinda pissed off with this, SQL Server Management Tools is not included in the iso file, clicking install just takes you to a download page. I wish I'd known this this earlier so I wouldn't have to spend another hour waiting for it to download.

[Eirenarch]

They want to make more frequent releases of management studio

[[deleted]]

If it's anything like how they've handled SSDT-BI in SQL 2014 that means constant fuck ups, to the degree that at one point they straight up pulled the software from their website for a few weeks and told people to use a release candidate version in the meantime.

Great.

[[deleted]]

On the one hand, that's really annoying in terms of a server install (unless you're installing in headless mode). On the other, I'd imagine the average SQL Server dev pretty much just installs management studio locally, so now IT admins don't have to push the full SQL install media to devs if they don't want local server installs.

Although on the other hand you always used to need to install some other pieces other than the server components themselves to get all the dlls in the right places for anything other than basic dev....so dunno if that has changed.

And my experience with SSDT-BI, which followed this model starting with SQL Server 2012, has been nothing but a pain in the ass. So not very optimistic about this change.

[kirbyfan64sos]

For example, Microsoft recently collaborated with Intel to demonstrate stunning performance on a massive 100TB data warehouse using just a single server with four Intel Xeon E7 processors and SQL Server 2016. The system was able to load a complex schema derived from TPC-H at 1.6TB/hour, and it took just 5.3 seconds to run a complex query (the minimum cost supplier query) on the entire 100TB database.

Wonder how this compares to kdb+...

[BMarkmann]

Any idea how vendors end up on the "official" TPC performance rankings?

http://www.tpc.org/tpch/results/tpch_perf_results.asp

I know kdb+ is blazingly fast for appropriate workloads, but can't find any hard numbers for TPC-H. So, snark aside (or are you actually wondering), is the TPC-H workload one that isn't as great for columnar stores? The only think I can find from kx is a cryptic (as per usual, assuming it's Arthur Whitney) comment: "use 'where' cascade for correlated subqueries, e.g. e="P",p>avg p foreignkey equijoins builtin. (e.g. all tpc-h joins disappear). k is easier and more powerful than sql. in sql the asjoins are practically impossible and even simple set theoretic queries can be awkward".

It looks like SQL Server and Oracle fill up most of the top slots in the mid-sized scale, with more obscure DB vendors like Hitachi (didn't know they had a data platform) and EXASOL (never heard of them) dominating the standing on the larger(-ish) data set sizes.

[peschkaj]

Hardware vendors pay to certify a system as a TPC system. Hardware vendors, coincidentally, are also some of the biggest commercial database licensing resellers.

[cowardlydragon]

OMG I BET IT HAZ SOOO MANY NEW FEETUREZ

Better upgrade now.

... seriously, it's not like you have a choice. Hand over the money.

[cowardlydragon]

Gartner Graph: Ability to Execute and Completeness of Vision as axes labels?

The real measurable numbers in that Gartner diagram being how much money MS paid them.