September 19, 2014 at 9:20 am
Steve Jones - SSC Editor (9/19/2014)
Barry G Freeman (9/19/2014)
I'm a great believer in "If it ain't broke, don't fix it" and so if a system is running acceptably for it's purpose, I'll leave it alone.
I agree. This is me, and a reason why I'd struggle to justify a 2000 upgrade at this point. If it's been working this long, it's probably OK.
I was happy to upgrade our SQL2000 to 2008R2... .get true 64bit with being able to take advantage of much more memory AND database backup compression. I also like how they have changed applying CU and SPs to SQL Server as well. 2012 and 2014 have some nice features but unless you are a high end app you will never use those.
September 19, 2014 at 9:25 am
Time to convert and regression test has been my main obstacles ever since 6.0.
So far I have tried to do most upgrades of SQL to coincide with scheduled upgrades to hardware. Which generally means an upgrade every 5 years. Some times have had to fight hard to be allowed to go to the newest version, and have a couple of times delayed hardware upgrade just to make the newest version have some traction before upgrading.
September 19, 2014 at 9:53 am
A couple of things that are not new but one that might be a little unique.
1. Cost of product
2. Cost of testing
3. Cost of and issues with various licenses
4. Old code in both COTS and in house developed products that is almost impossible to change without rewriting part or all of the product.
5. Lack of legacy applications complying with the standard that the app once deployed belongs to operations and that application should be configured and constructed such that ops can move it at will.
Happy Friday!
Not all gray hairs are Dinosaurs!
September 19, 2014 at 10:14 am
Updatable ColumnStore indexes, in-memory OLTP tables, and Delayed Durability are game changing features for which the SQL Server engineering team should be applauded. However, I still think Microsoft marketing department should have named it SQL Server 2012 R2.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 19, 2014 at 10:31 am
Eric M Russell (9/19/2014)
Updatable ColumnStore indexes, in-memory OLTP tables, and Delayed Durability are game changing features for which the SQL Server engineering team should be applauded. However, I still think Microsoft marketing department should have named it SQL Server 2012 R2.
Personally R2 releases are a bad idea to me especially when the year is in the version name. It seems old over time. I know on the SQL2008 side too many people get too confused over 2008 and 2008R2. We bought a new app and I specifically asked them which version they supported and they said SQL2008. Got it all installed and come time to install the app and it failed because it was looking for 2008R2. The marketing team appologized to me over that oversight. So I had to deinstall and install R2.
September 19, 2014 at 10:40 am
Markus (9/19/2014)
Personally R2 releases are a bad idea to me especially when the year is in the version name. It seems old over time. I know on the SQL2008 side too many people get too confused over 2008 and 2008R2. We bought a new app and I specifically asked them which version they supported and they said SQL2008. Got it all installed and come time to install the app and it failed because it was looking for 2008R2. The marketing team appologized to me over that oversight. So I had to deinstall and install R2.
So Microsoft should name its products in a way that no one could get the name wrong? As long as there is a name there is a possibility that someone will get it wrong. Microsoft should not be blamed due to the error of the other vendor?
🙂
Not all gray hairs are Dinosaurs!
September 19, 2014 at 10:44 am
troy.smyrnios (9/19/2014)
In two words - regression testing.It is a costly endeavor, even for those systems that aren't considered "regulated".
I second that! It takes time to evaluate current software against a new version of SQL Server. When 2012 came out, I read the new features list, evaluated it on my computer, and told my boss there wasn't any value to the upgrade from our 2008/2008 R2 instances, since practically all the enhancements were to BI functionality that as a business we'd be years away from ever using anyway, and we'd have to go through a new process to upgrade our SSIS packages (and they didn't make the 2012 Management Studio able to work with SSIS packages on 2008 servers properly), in addition to all the regression testing.
Part of the problem is, in the overall scheme of things, SQL Server's database engine doesn't and shouldn't need to change as much or as frequently as the other bundled software within what we call SQL Server. Don't get me wrong, it's great to have IS, RS, AS all bundled, but Microsoft ties them into each other so closely that they can't unbundle them, thus requiring upgrades to everything whether needed or not.
In my 20+ IT career, the times have been few and far between when we've upgraded a database engine because of a new feature we wanted, yet Microsoft product development seems so tied to adding every wiz-bang feature they think is cutting edge, even if they only get them half right like columnstore indexes in 2012 or hekaton in 2014.
September 19, 2014 at 10:47 am
Miles Neale (9/19/2014)
Markus (9/19/2014)
Personally R2 releases are a bad idea to me especially when the year is in the version name. It seems old over time. I know on the SQL2008 side too many people get too confused over 2008 and 2008R2. We bought a new app and I specifically asked them which version they supported and they said SQL2008. Got it all installed and come time to install the app and it failed because it was looking for 2008R2. The marketing team appologized to me over that oversight. So I had to deinstall and install R2.So Microsoft should name its products in a way that no one could get the name wrong? As long as there is a name there is a possibility that someone will get it wrong. Microsoft should not be blamed due to the error of the other vendor?
🙂
It should have just been called SQL Server 2010 since it came out in December 2010.
September 19, 2014 at 10:50 am
I too take issue with the use of year as a piece of software's version number. At least the MS OS team have given up on the idea. I don't like names for versions much either. Is it Vista that is 6.1? Don't bother answer. It was rhetorical whether right or wrong.
EDIT: Typo!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 19, 2014 at 10:50 am
Our issue is that we are still on Windows Server 2003, in most cases. One of the obstacles to resolving that has been that we use numerous SAN clones/snapshots to refresh databases daily for development and testing. You can't mix Windows versions when doing that. We're currently trying to figure out how to do upgrade Windows with minimal impact to that process.
September 19, 2014 at 11:11 am
With our CR process it takes me a week to get a procedure change pushed. A full version upgrade on a production DB would take about 1 year and an act of Congress. I like to upgrade to always have access to new features, but servers supporting vendor apps usually have to lag far behind due to regression testing.
Aigle de Guerre!
September 19, 2014 at 11:21 am
Gary Varga (9/19/2014)
I too take issue with the use of year as a piece of software's version number.
Truth be told I kind of like the preproduction code names assigned to the products.
Not all gray hairs are Dinosaurs!
September 19, 2014 at 11:37 am
Miles Neale (9/19/2014)
Gary Varga (9/19/2014)
I too take issue with the use of year as a piece of software's version number.Truth be told I kind of like the preproduction code names assigned to the products.
I'd hate to keep track of terms like Kilimanjaro versus Denali and Juneau when discussing SQL Server version releases. I like version release names based on year of major release, because they are logical and unambiguous, but at the same time the release schedule should go something like: major release, minor R2 release 2 years later, next major release 2 years later, etc. Also, each minor R2 release should be engineered technically and marketed economically to be a smooth migration from the previous major release.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 19, 2014 at 12:27 pm
Eric M Russell (9/19/2014)
I'd hate to keep track of terms like Kilimanjaro versus Denali and Juneau when discussing SQL Server version releases. I like version release names based on year of major release, because they are logical and unambiguous...
Eric, I agree with you for the most part but I still like the preprod names since up here we see and hear of them quite often.
Problem is that even in recent history there has been some trouble with the release/year/version pattern. Consider the following:
SQL Server 10.0 Katmi came out in 2008 the production release is SQL Server 2008
SQL Server 10.25 CloudDatabase came out in 2010 the production release is SQL Azure DB
SQL Server 10.50 Kilimanjaro came out in 2010 the production release is SQL Server 2008 R2
All three versions are versions of SQL Server 10.x. Shouldn't the 10.25 version be Release 2 of SQL 10? In addition, the 10.50 version be Release 3. They stemmed from the same codebase, sequentially, and logically? It is odd that 10.25 broke pattern and is not SQL 2008 Azure or 2008 something.
But, who knows the mind of Microsoft?
Not all gray hairs are Dinosaurs!
September 19, 2014 at 1:09 pm
Meow Now (9/19/2014)
With our CR process it takes me a week to get a procedure change pushed. A full version upgrade on a production DB would take about 1 year and an act of Congress.
Is it possible to "like" a post over here??? this one deserves it!
The main reason NOT to upgrade, for me, is cost. But not only licensing cost - it is the time of the entire development team cost. To properly test a new version we would have to stall the development of new projects, and new products bring money in - upgrading servers doesn't.
Also in some cases the applications are just out of support and not compatible with newer versions. That SQL Server 7.0/2000 of mine will remain on the company for more years than I will. I guess it's some kind of highlander server, it just wont die.
Viewing 15 posts - 31 through 45 (of 69 total)
You must be logged in to reply to this topic. Login to reply