Would love to use SQL Server 2005 but I am a developer

When we install our system we attach our database to SQL Servers that our
customers have.
It has to be this way as there are lots of pre-configured data in DB etc.
Besides it is easier than using scripts.

It appears that when SQL Server 2000 database is attached to SQL Server
2005, the server alters database structure, and database becomes
incompatible with SQL Server 2000.

What it means is that as a developer, I cannot use SQL Server 2005, until
basically the very last customer we have, switched to SQL 2005. I have to be
the last to get my hands on new technology ! Because if I do switch to SQL
Server 2005, and let it handle my database, that database will not work
under our customers SQL Server 2000.

Is not it nice ? Great work, Microsoft !

Alex  wrote:
> When we install our system we attach our database to SQL Servers that our
> customers have.
> It has to be this way as there are lots of pre-configured data in DB etc.
> Besides it is easier than using scripts.
>
> It appears that when SQL Server 2000 database is attached to SQL Server
> 2005, the server alters database structure, and database becomes
> incompatible with SQL Server 2000.
>
> What it means is that as a developer, I cannot use SQL Server 2005, until
> basically the very last customer we have, switched to SQL 2005. I have to 
be
> the last to get my hands on new technology ! Because if I do switch to SQL
> Server 2005, and let it handle my database, that database will not work
> under our customers SQL Server 2000.
>
> Is not it nice ? Great work, Microsoft !

I'm not sure I understand your scenario. If your customers are using
2000 then what is the point on developing in 2005? You obviously
wouldn't be able to take advantage of any new features no matter what
method you choose to deploy the database.

Detaching and re-attaching databases doesn't make much sense as a
deployment method unless it is for a clean install of a new system. If
that's the case then I don't know why you wouldn't deploy it with a
script. You have to deploy incremental releases by script presumably?

So assuming you do want to use the detach / reattach method, why not
script your database onto a test SQL Server 2000 and then detach it
from there.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--

But you can administer the database from an installed managment studio.
if your customers are using SQL 2000, what would be the deal for you
using SQL 2k5 ? As a developer I would always develop on nearly the
same enviroment, that my application will be rolled out not having any
suprises or side effect at delivery time.

Jens Suessmeyer.

---
http://www.sqlserver2005.de
---

> I'm not sure I understand your scenario. If your customers are  using

> 2000 then what is the point on developing in 2005? You obviously
> wouldn't be able to take advantage of any new features no matter what
> method you choose to deploy the database.

What is the point in moving from NT to 2000 to XP ?
Same thing here. Trying to get the best out of technology and lead the way.
For last 7 or 8 years we had no problem with SQL server, now we do, but you
do not see it.

We have hundreds of customers all over the world.
We are stuck with SQL2000 until the very last of them migrates to SQL2005.
You see no problem here ?

> Detaching and re-attaching databases doesn't make much sense as a
> deployment method unless it is for a clean install of a new system.
> If that's the case then I don't know why you wouldn't deploy it with a
> script.

It is your point of view, nothing more.

Why would we generate SQL script to create DB and  tables and views etc, and
then scripts to add all the data, instead of just a simple detach/attach
operation ? Why ?

And we have a process that upgrades database using the same detach/attach
method. You just give it an old DB and the new DB and it does the job
keeping all the data. Not a single change required to this process as we
make changes to to the new DB, it is fully automated.

What you suggest is to write biillions of scripts.
If you cannot think outside of the square, do not advice, mate.

> So assuming you do want to use the detach / reattach method, why not
> script your database onto a test SQL Server 2000 and then detach it
> from there.

I just want to develop on my machine using the latest DB engine. When I am
ready to release an upgrade, I want to : detach, send to a customer, attach.
Works perfectly.

Alex wrote  on Fri, 7 Apr 2006 19:39:20 +1000:

> We have hundreds of customers all over the world.
> We are stuck with SQL2000 until the very last of them migrates to SQL2005.
> You see no problem here ?
> 
>
> It is your point of view, nothing more.
>
> Why would we generate SQL script to create DB and  tables and views etc,
> and then scripts to add all the data, instead of just a simple
> detach/attach operation ? Why ?

So you want to use the latest engine, which requires changes to the
structure, and yet you complain that it does so. It's not like MS is holding
a gun to your head and forcing you to move to SQL Server 2005.

> And we have a process that upgrades database using the same detach/attach
> method. You just give it an old DB and the new DB and it does the job
> keeping all the data. Not a single change required to this process as we
> make changes to to the new DB, it is fully automated.
>
> What you suggest is to write biillions of scripts.
> If you cannot think outside of the square, do not advice, mate.

Why write "billions of scripts"? You can script out the entire database
using Management Studio in just a couple of clicks, you don't have to write
it all from scratch.
 
>
> I just want to develop on my machine using the latest DB engine. When I am
> ready to release an upgrade, I want to : detach, send to a customer,
> attach. Works perfectly.

What you want is for SQL Server 2005 to work just like SQL Server 2000 -
easy solution is just to use SQL Server 2000.

Dan

> So you want to use the latest engine, which requires changes to the
> structure, and yet you complain that it does so. It's not like MS is
> holding a gun to your head and forcing you to move to SQL Server 2005.

You just do not get it do you.

If I have a 1000 customers and 500 of them switched to SQL2005. I still have
to stick to SQL2000 because 500 other of my customers are still using it.
Then fist 500 customers say : "Hey, how about using this and that new
feature presented by SQL 2005 ?"

What do I say to them ? Make a union ! Use either 2000 or 2005 but all
together !

Alex  wrote: 
>
> What is the point in moving from NT to 2000 to XP ?
> Same thing here. Trying to get the best out of technology and lead the way
.
> For last 7 or 8 years we had no problem with SQL server, now we do, but yo
u
> do not see it.
>
> We have hundreds of customers all over the world.
> We are stuck with SQL2000 until the very last of them migrates to SQL2005.
> You see no problem here ?
>

Nonsense. Assuming your code base is compatible then you can run both
environments. On the same server if necessary. You would have to do
that in any case. Surely you wouldn't release a product to a customer
without having tested it on their version of the server?


> And we have a process that upgrades database using the same detach/attach
> method. You just give it an old DB and the new DB and it does the job
> keeping all the data. Not a single change required to this process as we
> make changes to to the new DB, it is fully automated.
>
> What you suggest is to write biillions of scripts.
> If you cannot think outside of the square, do not advice, mate.

You can generate scripts automatically using SQL Server or any number
of third party products. If you don't save your scripts to a source
control database anyway then your method of operation is different from
any development shop I've ever worked with.

 
>
> I just want to develop on my machine using the latest DB engine. When I am
> ready to release an upgrade, I want to : detach, send to a customer, attac
h.
> Works perfectly.

Then do just that.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--

Alex  wrote: 
>
> You just do not get it do you.
>
> If I have a 1000 customers and 500 of them switched to SQL2005. I still ha
ve
> to stick to SQL2000 because 500 other of my customers are still using it.
> Then fist 500 customers say : "Hey, how about using this and that new
> feature presented by SQL 2005 ?"
>
> What do I say to them ? Make a union ! Use either 2000 or 2005 but all
> together !

I do not understand what stops you using both products. How can you
test in a compatible environment if you don't have the same version as
the customer?

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--

Alex wrote  on Fri, 7 Apr 2006 20:50:43 +1000:
 
>
> You just do not get it do you.
>
> If I have a 1000 customers and 500 of them switched to SQL2005. I still
> have to stick to SQL2000 because 500 other of my customers are still using
> it. Then fist 500 customers say : "Hey, how about using this and that new
> feature presented by SQL 2005 ?"
>
> What do I say to them ? Make a union ! Use either 2000 or 2005 but all
> together !
>

If your customers want new features, tell them they have to pay for it and
run two release versions. Run 2005 and 2000 at the same time, develop on
both. What you want is for MS to upgrade 2000 to give it the same features
as 2005 - why would anybody bother buying 2005 if they did that? Think about
from a business perspective.

Dan

Sorry, but I totally agree with David and the other respondents, and by the
way, Alex, there's no need to be rude, even if it was not intentional.

Jan Van der Eecken


"Alex" <alex@nospam.com> wrote in message
 news:4436334c$0$2060
6$5a62ac22@per-qv1-newsreader-01.iinet.net.au... 
>
> What is the point in moving from NT to 2000 to XP ?
> Same thing here. Trying to get the best out of technology and lead the
> way.
> For last 7 or 8 years we had no problem with SQL server, now we do, but
> you do not see it.
>
> We have hundreds of customers all over the world.
> We are stuck with SQL2000 until the very last of them migrates to SQL2005.
> You see no problem here ?
> 
>
> It is your point of view, nothing more.
>
> Why would we generate SQL script to create DB and  tables and views etc,
> and then scripts to add all the data, instead of just a simple
> detach/attach operation ? Why ?
>
> And we have a process that upgrades database using the same detach/attach
> method. You just give it an old DB and the new DB and it does the job
> keeping all the data. Not a single change required to this process as we
> make changes to to the new DB, it is fully automated.
>
> What you suggest is to write biillions of scripts.
> If you cannot think outside of the square, do not advice, mate.
> 
>
> I just want to develop on my machine using the latest DB engine. When I am
> ready to release an upgrade, I want to : detach, send to a customer,
> attach. Works perfectly.
>
>
>