September 2, 2015 at 9:53 pm
Comments posted to this topic are about the item The Case for Upgrading
September 3, 2015 at 12:57 am
Steve
Microsoft may be shooting themselves in the foot in this instance but as a business they look at how they can make the most money which, regrettably, doesn't necessarily mean keeping their smallest customers happy. That's business.
Small customers may well move to a competitor and maybe they will find the competitor values their custom more highly. That's an opportunity for the new supplier. If Microsoft choose not to compete in this part of the market that's a decision that may come back to bite them.
September 3, 2015 at 1:26 am
I don't think its probably an issue for those kind of small Access / VBA applications. Some of those applications can be complicated but typically will be internal only applications often with really quite rich interface for really quite obscure processes and only for a hand-full of individuals. Security should be less of an issue simply because they may well just be LAN based meaning the attack surface might be tiny.
Review once a year and periodically test set up on new operating system versions. Know how to set up the systems and backup.
Digital should mean immortality - that was supposed to be the benefit of going digital!
September 3, 2015 at 1:27 am
Firstly, if it ain't broke, don't fix it.
Secondly, is this not a task for the sysadmins? They are responsible for security. If they are happy that the server is nicely isolated and protected within the network, then why upgrade? What do they say about it?
Another thought that comes to mind, and this comment is tempered by the fact that I know nothing about their DB and what it does, is that if constancy and cost are important, would it be worthwhile to consider a major migration to a system based on SQL Server Express Edition? Several instances would be needed to allow for the use of multiple cores. The current DB would have to be chopped up into 10GB chunks and distributed over the 4 instances. SSIS packets would have to be re-written as SQL scripts that would be run by the Windows Scheduler. They would still be able to use SSRS too.
It is a lot of work but the benefit would be the ability to upgrade to newer versions of SQL Server Express Edition with no licence costs and little to no compatibilty problems as well as being able to take advantage of newer features. Distributed transactions would have to be carefully thought through. Replication would coem in very useful here. It may also be a chance to greatly optimise the performance of the DB and add in archiving, as an example. If their DB is 25GB, this won't be too painful. If it is 250GB, it might be a different story.
I'm if the opinion that Microsoft releases their products much too often. They should introduce a 5-year cycle with support over 2 cycles (10 years). The resulting product, though, should be so good, and so well tested that the decision to go with the new release should be what out American cousins refer to as a 'no brainer'. At the moment, we get a drip-feed of new releases every 2-3 years and rarely is a release so good that the decison to upgrade is clear. It was with SQL Server 2005. I thought that it was so with the In-Memory-OLTP in SQL Server 2014 until I tried it with our current DB.
September 3, 2015 at 1:44 am
I think Microsoft would be better served by letting customers license the scale they need
You mean similar as Oracle where you have to multiply your real cores by a factor definde by the exact type of the core?
September 3, 2015 at 6:12 am
We ran smack into this earlier this year. We've got 2005 SP4 running and went through the whole exercise of costing out a move all the way to SS2014. With all the ifs, and, buts, ors, provisos and quid pro quos it worked out to like $9000 per year over three years. And that was for standard edition.
Needless to say the bean counters had a coronary and said no way. Moving to 2008 would have been significantly cheaper but still pretty hideous.
Microsoft's attitude is for small businesses to use SQL Server Express which is free, mostly functional and has some other limitations.
Frankly, I've never understood the justification for across-the-board core-based licensing. I think it would be better if they used that for Enterprise Edition (maybe even BI Edition) and returned to a per-server or per-copy license for Standard and below. It would give mid-sized companies a more affordable alternative.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 3, 2015 at 6:27 am
SQL Server is expensive. It also needs an NT Server licence. One realistically needs new licences every 7 or so years.
This must be realised by senior management when the decision to go Microsoft is made. And it is usually they who make that decision. Let them believe Microsoft's mantra that every new version of a Microsoft product reduces the total cost of ownership. If the beancounters complain about the cost of new licences, then refer them to the ones who made the decison to get SQL Server in the first place.
If cost is an issue, start training up staff in Linux and PostgresSQL. It costs in the short term but pays off in the medium-to-long term. They are neither as nice or as user-friendly as products from Microsoft and the pool of potential staff is smaller, but it is doable.
September 3, 2015 at 7:06 am
We just upgraded our last few SQL2000 dbs to 2008R2 earlier this year and that was a very large project that took over 2 years to complete as it was a massive system with over 50 databases. We are actively moving things off of 2005 to 2012. This is a constant battle and will be even worse when 2008 goes out of extended support in 2019 because we have 60% of everything in 2008/2008R2. We are attempting to be more agressive with upgrades but the costs are quite high. With Microsoft coming out with SQL2014 23 months after SQL2012 it makes our job much more difficult. 2008R2 came out less than 2 years before 2012. We have well over 500 production databases and I just don't see how we can keep up with just upgrades.
September 3, 2015 at 7:08 am
I think you upgrade either a) when it's needed, or b) when you have sufficient resources and time to do it without causing a disruption in your operations to gain new function that will benefit the organization.
And by when it's needed, I mean that you see that finding the hardware that your OS/software will work with properly is becoming all too difficult...and it provides the looming possibility that you might lose function of systems totally if you don't.
I have seen this at one city where I worked. They had an HP mainframe. An older one. And, getting replacement parts through 3rd party suppliers was becoming harder and harder. They seriously needed to look at a newer system, but the city council was too busy dumping money in the pocket of a local construction contractor whose renovation of an old building to become their "new" city hall was about 5 years overdue and 4x the original budget already. Their priorities were obviously in the wrong place. But, there was nothing IT could do about it.
On the other hand, I actually know a county government where I worked, and they have an old, old PC running as a Linux server and it's been online over 10 years. They keep a few spare drives, some spare RAM, and a couple of spare motherboards. That way if a component goes down, they replace it and do what's needed to bring the box back up online ASAP.
But as I think someone said earlier: "don't fix what ain't broke". They're wise words.
September 3, 2015 at 7:27 am
Markus (9/3/2015)
We just upgraded our last few SQL2000 dbs to 2008R2 earlier this year and that was a very large project that took over 2 years to complete as it was a massive system with over 50 databases. We are actively moving things off of 2005 to 2012. This is a constant battle and will be even worse when 2008 goes out of extended support in 2019 because we have 60% of everything in 2008/2008R2. We are attempting to be more agressive with upgrades but the costs are quite high. With Microsoft coming out with SQL2014 23 months after SQL2012 it makes our job much more difficult. 2008R2 came out less than 2 years before 2012. We have well over 500 production databases and I just don't see how we can keep up with just upgrades.
hear, hear
---------------------------------------------------------------------
September 3, 2015 at 7:31 am
Just curious what type of code changes would be needed for a MS Access application originally designed for SQL Server 2005 to support SQL Server 2014 ?
Of course the connection string or DSN would need to change, and maybe some retrofitting to the Data Access Layer, but I wouldn't expect it to require a major overhaul. I would expect the SQL, reports, GUI, line of business programming, etc. would all remain the same.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 3, 2015 at 8:18 am
Eric M Russell (9/3/2015)
Just curious what type of code changes would be needed for a MS Access application originally designed for SQL Server 2005 to support SQL Server 2014 ?Of course the connection string or DSN would need to change, and maybe some retrofitting to the Data Access Layer, but I wouldn't expect it to require a major overhaul. I would expect the SQL, reports, GUI, line of business programming, etc. would all remain the same.
If the Access/VBA code was well written, then I would have to agree. I would expect the number of changes to be minimal. This could be tested by converting the database to SQL Express 20XX, assuming SQL Express can handle this database.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
September 3, 2015 at 8:35 am
Years ago I was involved in a SQL Server 2000 -> 2005 migration. There was a 3rd party hardware interface application that would not connect to SQL Server 2005. From what I recall, the vendor wanted $$,$$$ to modify the app. No customized programming mind you, basically just recompiling the app so that it would work with the new v2005 provider library. Ostensively this was considered a customized request just for us, although I image there must have been several such requests from other clients as well.
The database layer was just a couple of stored procedures that performed basic lookup query and insert operations. So, what we did instead was switch the app the connect to a SQL Server 2000 Express instance installed locally on the application server, and then we modified the stored procedures to link to the new SQL Server 2005 instance. It worked like a charm for the few month period that it took us to change vendors.
Moral of the story: Adapt or die.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 3, 2015 at 8:40 am
Eric M Russell (9/3/2015)
Years ago I was involved in a SQL Server 2000 -> 2005 migration. There was a 3rd party hardware interface application that would not connect to SQL Server 2005. From what I recall, the vendor wanted $$,$$$ to modify the app. No customized programming mind you, basically just recompiling the app so that it would work with the new v2005 provider library. Ostensively this was considered a customized request just for us, although I image there must have been several such requests from other clients as well.The database layer was just a couple of stored procedures that performed basic lookup query and insert operations. So, what we did instead was switch the app the connect to a SQL Server 2000 Express instance installed locally on the application server, and then we modified the stored procedures to link to the new SQL Server 2005 instance. It worked like a charm for the few month period that it took us to change vendors.
Moral of the story: Adapt or die.
Resistance is futile. You shall be adapted, or discarded! 😎
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
September 3, 2015 at 8:50 am
Alvin Ramard (9/3/2015)
Eric M Russell (9/3/2015)
Years ago I was involved in a SQL Server 2000 -> 2005 migration. There was a 3rd party hardware interface application that would not connect to SQL Server 2005. From what I recall, the vendor wanted $$,$$$ to modify the app. No customized programming mind you, basically just recompiling the app so that it would work with the new v2005 provider library. Ostensively this was considered a customized request just for us, although I image there must have been several such requests from other clients as well.The database layer was just a couple of stored procedures that performed basic lookup query and insert operations. So, what we did instead was switch the app the connect to a SQL Server 2000 Express instance installed locally on the application server, and then we modified the stored procedures to link to the new SQL Server 2005 instance. It worked like a charm for the few month period that it took us to change vendors.
Moral of the story: Adapt or die.
Resistance is futile. You shall be adapted, or discarded! 😎
Yes, tis better to be proactive and adapt oneself than wait for someone else to do the adapting.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 34 total)
You must be logged in to reply to this topic. Login to reply