views:

442

answers:

6

What would you say if a developer wanted to implement a sql2008 dev environment, but we were still forced to use a sql2000 test and sql2000 production environment?

Would there be anything wrong with using sql2008 on a dev server? Of course you'd need to know what functionality you couldn't use, so you didn't have problems migrating your work from the sql2008 servers to sql2000.

+1  A: 

Using Basic SQL features - you'll do OK.

I have no idea why you use this environment, but it is best to use as similar environment and DEV, QA and Production as possible, to avoid surprise when going on production.

I think that SQL 2000 uses OLEDB and SQL 2008 you can use ADO.NET provider, And there might be many more differences that you might bump into. so the best advise it NOT TO DO SO.

Dani
+1  A: 

I don't see why you'd have a development environment using a newer version of SQL server if your staging and production environments aren't.

No matter what software will act different based on version, and there could be a bug that could come up by not keeping the same versions. I'd recommend using the same versions across your entire environment.

William
+2  A: 

I'd strongly avoid developing on a different local version than the dev/qa/prod environments. Most of the time nothing will happen, but when it does it can take forever to track down the issue. Not only that, you may never be able to replicate it locally since you have a different environment.

Stephane Grenier
A: 

What is there to gain by using 2008 over 2000 if you know you have get it to work in 2000?

There are so many issues with doing this:

  1. Performance could be totally different even with the exact same SQL
  2. DTS packages are handled totally different
  3. You could unknowingly use code that is incompatible with SQL2000. You would not know until you moved it to test or live and by this point you could have done a lot of wasted development around incompatible code.
  4. etc etc etc...

There is absolutely no reason to use a different version for dev than your LIVE environment. It will just end up causing you grief and inconsistencies.

Kelsey
-1 for being a hypocrite
Germ
+1  A: 

How about setting up a Virtual Machine (eg. under Virtual Server 2005 R2 SP1 w/Update) that has the SQL Server 2008 environment on it? This would ensure that you don't contaminate your SQL 2000 environments with it, while at the same time allowing you to try things out. You can either set this up as a VM on a separate machine, or simply add it as a VM on you own development machine.

Joe L.
+1  A: 

I think best practice would be to keep all of your environments the same. I can see it being userful to try out new functionality on the new environment to determine if it would be benefical updating your test and live systems.

Germ