January 13, 2010 at 7:51 am
Steve, I hear where you're coming from, and I do think it's a nice to have, but the traditional approach of restoring from pre-upgrade backup would still be valid.
I think where it would be useful is if you're moving DBs between different servers that are on different versions, in a test environment for example.
January 13, 2010 at 8:10 am
If the server running SQL Server has been virtualized it would be possible to make a snapshot before the upgrade, then roll back to that snapshot later if needed. Of course, any data changes would be lost after the roll back. We have recently moved to a VMware infrastructure which provides this functionality.
January 13, 2010 at 8:36 am
Sometimes the only way you get progress is to force it down customer's/user's throats.
As much as I hate to say it, that is the painful reality. If it was easy to regress after an upgrade there would be many more people demanding support for outdated versions of software and refusing to upgrade.
The standard reason would be "I tried it and didn't like it."
Preventing or making it extremely difficult to backslide forces one to get past the learning curve.
Thanks, Bobw
(Currently suffering from self induced wounds from forcing myself to upgrade to Windows 7 Pro. Please don't pour any salt on them, I have enough already...)
January 13, 2010 at 9:28 am
I'm not trying to stifle progress here. And 55 votes on Connect mean that it's more than a little important to people. someone even had a great comment that they'd like to be able to go back and see there things are performing differently.
There are ways to do this, and perhaps if this works with third party products that's enough. It seemed to me, however, that if I upgraded AND made changes, meaning a few days of work, I might want to go back if I have performance problems.
Not permanently, but go back long enough to determine what's wrong and what I can do to fix it. Note that going back doesn't mean a refund on my upgrade cost. That alone will force me to go forward soon enough.
January 13, 2010 at 12:08 pm
My company writes software that is "off the shelf" meaning we try hard not to customizations for each user, but is very industry specific. We've been asked this question by users a few times in the last twenty years, they always think it would be rather easy for us to allow them to "downgrade" to a previous version.
The bottom line is it takes a lot of work to get a version change done correctly, and a lot of testing. The number of situations we would have to evaluate to let folks move backwards a version (or two or five) would take considerable amount of time away from my developers. And everyone (us, individual customer, and customer base in general) are better off if we keep grouping all the users towards the more recent versions. We have less versions to support, we have bug fixes built in to newer versions, and the differences that make users cringe in a new version are there for their own benefit.
Bottom line: It's seldom actually needed, and very expensive to do properly. If a user really wants to go back, they presumably have last night's backup. The amount of work and/or data they will lose from today is far less than the work we'd have to do to make such seamless "backgrades" possible.
Student of SQL and Golf, Master of Neither
January 13, 2010 at 1:38 pm
It is really a business decision on the part of Microsoft not to spend the resources to add a feature that will only rarely be needed.
If there is really a great need for this, why aren’t third party providers jumping in to provide a tool to do this? Probably because there is not enough demand to justify the resources required to develop it and to be able to make money.
January 13, 2010 at 2:27 pm
Our "going back" took the form of linking tables from the old (2005) application to the data in the upgraded (2008) application.
That way we could see up to date data through the eyes of the 2005 database.
We still saw the issue which was bothering use giving us the clue that it was an issue of data rather than db version.
January 13, 2010 at 2:32 pm
GSquared (1/13/2010)
I have to say I haven't yet run into a situation where I'd want to do this.Does RedGate's backup product use the SQL backup engine? I don't see how it could, since it offers backup compression on versions of SQL Server that don't do that. In that case, why have Microsoft build something that you can get from RedGate? It seems like it would do what you need. That would seem to bypass the issue. Anyone have a copy of SQL 2000 they can test that on?
Yes - RedGates backup product uses the SQL backup engine. So does Quest's Litespeed - and Idera's product. They get compression by using VDI to create a virtual device that can then be compressed. They get increased speed on the backup by using multiple virtual device files - compressing those files - then putting all of those files into a single destination file.
I think it is much harder than it sounds to be backward compatible. In SQL Server 2005 they included the option CHECKSUM for page verification. This means they had to make a change to how the pages are actually written to disk - and how those pages are stored in the backup file. Since a backup simply takes a copy of the page and stores it in the backup file - how would you take that page and store it in 2000 format?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 13, 2010 at 2:37 pm
Interesting discussion, especially since I'm following it from the viewpoint of a developer used to working on a DB that does offer this feature already; namely the IBM i.
When saving any object on the IBM i , there's a "target release" parameter which allows you to specify the current release, the previous release, or the second previous release.
It does make it quite nice supporting back level clients who may not move as quickly as you.
But it does mean you may not be able to take advantage of every new feature right away.
In addition, basically every object on the i also has a "earliest release supported on" attribute. So if you create something that uses new functionality in the new version of the OS, the system won't let you save it using a "target release" of anything besides current.
Charles Wilt
January 13, 2010 at 2:41 pm
I guess the discussion is moot anyway, since Microsoft feels like a few of you. They have rejected my Connect item, though it was interesting that the number of votes gotten today brought it to someone's attention.
Their answer was that the backup process and format hasn't really changed much. What has changed, as pointed out by a few people, is the page structures. So the backup process throwing out pages to the file means that an older version can't read those pages.
February 10, 2010 at 1:23 pm
I wonder if the feature is all that important? It seems to me to be something that would only get used very rarely, and for such infrequent use it should be possible to solve the problem in a different way. For example provide a linked database capability - have the old system able to gain access to the new system and copy the data using SQL queries (or put the trust the other way round). Maybe it could be done with DTS, or with BCP? And in extremis it's not all that difficult to generate a text file that contains a script to insert all the data, although it could be a mighty big file and you need to make a proper ordered script generator (to avoid screw-ups with referential consistency) unless you are going to insert the data first and add the constraints later.
Tom
September 4, 2014 at 2:10 am
TomThomson (2/10/2010)
I wonder if the feature is all that important? It seems to me to be something that would only get used very rarely, and for such infrequent use it should be possible to solve the problem in a different way. For example provide a linked database capability - have the old system able to gain access to the new system and copy the data using SQL queries (or put the trust the other way round). Maybe it could be done with DTS, or with BCP? And in extremis it's not all that difficult to generate a text file that contains a script to insert all the data, although it could be a mighty big file and you need to make a proper ordered script generator (to avoid screw-ups with referential consistency) unless you are going to insert the data first and add the constraints later.
I think that this covers it for me. It can be done even if by restoring to a different instance of the same version then utilise an export/import strategy that fits with the data profile of the said database to get it into an instance of a previous version.
Too much else that I personally would prioritise over this.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 4, 2014 at 8:38 am
I think the reason this isn't there is to pressure organizations to upgrade ALL their servers. If one could move the database back, then they might migrate a database from a newer version to a server running the older version. As it is, this puts pressure to keep all the servers current.
I am certain it is a business decision as much a technical one.
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply