January 12, 2010 at 9:57 pm
Comments posted to this topic are about the item Why Can't We Go Backwards?
January 13, 2010 at 2:34 am
While it would be a nice feature, I don't think it serves us well, especially with differences in datatypes between versions.
Sure you could try to force compatibility levels, but what happens if you have, say, a 2008 DB that you want to restore to 2005, and it has datetime2?
January 13, 2010 at 4:49 am
Interesting.
I currently have a situation which is perhaps similar. I want to go forwards compatible.
We have a server on SQL 2005 and we want to upgrade it to SQL 2008. It would be really nice if we could just detach the databases, uninstall SQL 2005, install SQL 2008 and then reattach the databases.
But the question: is it that simple or will I encounter the issues you describe for backwards compatability when I go forwards?
January 13, 2010 at 6:19 am
rwilkes; Depending on the versions, it can be that simple. When the databases from the previous version are attached, SQL Server will upgrade the databases to the current version. Actually, it can be more simple. You can upgrade in place, and the installation will upgrade the databases during its process. But check the installation compatibilities. For instance, you cannot upgrade SQL Server 7 databases directly to SQL Server 2008.
Mark
January 13, 2010 at 6:39 am
Wow, thanks Mark. That almost sounds too good to be true!
We are going from SQL Server 2005 to 2008 so that probably helps make things fairly straight forward.
My only concern though is that you have suggested we could just upgrade with the dbs in place. I had heard it wasn't advisable to just upgrade, but that it was best to uninstall SQL Server 2005 before installing SQL Server 2008. Do you have a view on this?
(Obviously I'm all for the simple upgrade provided it doesn't have complicated connatations!)
January 13, 2010 at 6:45 am
You can do an upgrade. I don't see the sense in uninstalling 2005 first.
January 13, 2010 at 6:54 am
I have done both, with no noticeable problem either way. If it were a dedicated DB server, and running an older server OS, I would consider wiping it and installing latest OS (Windows Server 2008 R2) and a fresh clean install of SQL Server 2008. If the server has other functions/programs on it, an in-place upgrade may get you the benefits of SQL2008 quickly without reconfiguring other applications.
Mark
January 13, 2010 at 6:55 am
Going backwards is an issue if you have changed the database. However in many cases, it isn't that you've changed the database, it's that you moved it to the next version and without changing it, and having it in a lower compatibility mode, you want to go back.
January 13, 2010 at 6:58 am
Steve, agreed, which is why I think it would be a useful feature, but difficult to implement for the alternative (i.e. using the new features). For that amount of effort, scripting the DB out is "good enough". Yes?
EDIT: Clarified my statement.
January 13, 2010 at 7:17 am
I will have to disagree on this one. What are the reasons to go back? The big one is that problems pop up in the new version and you need to go back. But, isn't that what testing is about? Test the database on the new version of SQL and find those issues before migrating the production database.
Are there are other reasons to go back to a prior version?
What kind of support nightmare do you have when upgrading some customers then moving them back?
January 13, 2010 at 7:20 am
Mark Harr (1/13/2010)
I have done both, with no noticeable problem either way. If it were a dedicated DB server, and running an older server OS, I would consider wiping it and installing latest OS (Windows Server 2008 R2) and a fresh clean install of SQL Server 2008. If the server has other functions/programs on it, an in-place upgrade may get you the benefits of SQL2008 quickly without reconfiguring other applications.
Hi Mark, what you say adds up with what I have heard. The server in question IS a dedicated DB server running an older server OS. So I think perhaps the clean install may be my best route.
Thanks again.
Meanwhile I feel my forwards compatible query is perhaps getting in the way of Steve's backwards compatible theme. Thanks for everyone's help though..very useful.
January 13, 2010 at 7:23 am
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?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 13, 2010 at 7:28 am
In my experience, maintaining backward compatibility leads to unforseen and unnecessary problems in the code base.
Although it would be convenient, I see no "need" for this, and no real value added from this feature.
January 13, 2010 at 7:32 am
Wow, Steve. When you load a previous version's database into SQL Server the restore process modifies all the internal metadata to conform with the new version's requirements. Backups copy the page data for all used pages to the backup file. Do you really think that adding all the overhead to the backup program to process each page based on its intended version is a good idea? The real need for this occurs so seldom I don't think it's worth it at all. There are ways to go back, admittedly painful, but they exist. I'd really rather not have all that extra code in the product to do something that should rarely have to be done.
January 13, 2010 at 7:48 am
I do think it's valuable, and it would give people that have to upgrade some piece of mind. I see questions constantly where people need to go back after a few hours, or after performing an upgrade and realizing something isn't working.
I don't think this makes sense for the regular backups, but I would think that an automated way to move things back, would be helpful.
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply