making copy of 6.5 database to 7 or 2000

I have a 6.5 db that I want to create a copy of, I can move it to either
a machine running 7 or 2000. I am more used to doing this in Oracle so
pls bear with me...

I don't want to have any downtime on the 6.5 db, so I'm thinking perhaps
import is the best way to go? I am assuming that 6.5 backups are not
comaptible with either 7 or 2000 restore, or I'd go that route.

The database in question is fairly simple, pretty well just tables full
of data, no stored procs...

suggestions?

TIAHi

There are significant architectural differences between 6.5 and SQL
7/2000, and as you suppose the backups are not upgradeable. This
really only leaves you with the choice of DTS or script/BCP. If you
don't want to impact the live system I suggest that you restore a
backup into a separate database, preferably on a second machine.

John

Glen A Stromquist <glen_stromquist@.no.spam.yahoo.com> wrote in message news:<Qkfob.7041$EY3.2756@.edtnps84>...
> I have a 6.5 db that I want to create a copy of, I can move it to either
> a machine running 7 or 2000. I am more used to doing this in Oracle so
> pls bear with me...
> I don't want to have any downtime on the 6.5 db, so I'm thinking perhaps
> import is the best way to go? I am assuming that 6.5 backups are not
> comaptible with either 7 or 2000 restore, or I'd go that route.
> The database in question is fairly simple, pretty well just tables full
> of data, no stored procs...
> suggestions?
> TIA|||Glen A Stromquist <glen_stromquist@.no.spam.yahoo.com> wrote in message news:<Qkfob.7041$EY3.2756@.edtnps84>...
> I have a 6.5 db that I want to create a copy of, I can move it to either
> a machine running 7 or 2000. I am more used to doing this in Oracle so
> pls bear with me...
> I don't want to have any downtime on the 6.5 db, so I'm thinking perhaps
> import is the best way to go? I am assuming that 6.5 backups are not
> comaptible with either 7 or 2000 restore, or I'd go that route.
> The database in question is fairly simple, pretty well just tables full
> of data, no stored procs...
> suggestions?
> TIA

You can't restore 6.5 databases on SQL7/2000 (you can restore a SQL7
backup on SQL2000). If the database is quite simple, though, then it
should be straightforward to use BCP/DTS to transfer the data - script
the table structures, create them on the destination server, then copy
the data. DTS will create the tables for you, in fact. Or if the
volume of data isn't large, you could even create a linked server to
the SQL6.5 server, and simply INSERT... SELECT...

Simon|||I did not trust the microsoft upgrade wiz so what I did to move sql 6.5 to
2000 was:

1. Install all the SQL 2000 servers with a common collation order -
(Latin_General I think)

2. Create the DB name on SQL 2000

3. Script the tables in 6.5 with just create & object permissions

4. Install the script on 2000 and fix the application/script for field name
problems found. (Eg fields named Percent)

5. Use DTS to take the data from 6.5 to 2000 into these tables.

6. Script just primary key, indexes, triggers, DRI.

7. Sorted out the primary keys to install first on 2000. Then install the
indexes, triggers, foreign keys.

8. Switch over the users by changing the computer names of both machine -
such that the new machine gets the old machine's name.

With tested run of the steps 1 to 7 found that I only needed 30 min down
time so I got management to approve a 60 min downtime.

"Glen A Stromquist" <glen_stromquist@.no.spam.yahoo.com> wrote in message
news:Qkfob.7041$EY3.2756@.edtnps84...
> I have a 6.5 db that I want to create a copy of, I can move it to either
> a machine running 7 or 2000. I am more used to doing this in Oracle so
> pls bear with me...
> I don't want to have any downtime on the 6.5 db, so I'm thinking perhaps
> import is the best way to go? I am assuming that 6.5 backups are not
> comaptible with either 7 or 2000 restore, or I'd go that route.
> The database in question is fairly simple, pretty well just tables full
> of data, no stored procs...
> suggestions?
> TIA|||Hi

A couple of extras..

I would suggest that you keep your code in souce code control.
I would use BCP instead of DTS as you can recover/re-run from intermediate
stages.

John

"IanT" <IanNoSpam@.NoSpam.com.au> wrote in message
news:bo0doc$i2m$1@.perki.connect.com.au...
> I did not trust the microsoft upgrade wiz so what I did to move sql 6.5 to
> 2000 was:
> 1. Install all the SQL 2000 servers with a common collation order -
> (Latin_General I think)
> 2. Create the DB name on SQL 2000
> 3. Script the tables in 6.5 with just create & object permissions
> 4. Install the script on 2000 and fix the application/script for field
name
> problems found. (Eg fields named Percent)
> 5. Use DTS to take the data from 6.5 to 2000 into these tables.
> 6. Script just primary key, indexes, triggers, DRI.
> 7. Sorted out the primary keys to install first on 2000. Then install the
> indexes, triggers, foreign keys.
> 8. Switch over the users by changing the computer names of both machine -
> such that the new machine gets the old machine's name.
>
> With tested run of the steps 1 to 7 found that I only needed 30 min down
> time so I got management to approve a 60 min downtime.
>
>
> "Glen A Stromquist" <glen_stromquist@.no.spam.yahoo.com> wrote in message
> news:Qkfob.7041$EY3.2756@.edtnps84...
> > I have a 6.5 db that I want to create a copy of, I can move it to either
> > a machine running 7 or 2000. I am more used to doing this in Oracle so
> > pls bear with me...
> > I don't want to have any downtime on the 6.5 db, so I'm thinking perhaps
> > import is the best way to go? I am assuming that 6.5 backups are not
> > comaptible with either 7 or 2000 restore, or I'd go that route.
> > The database in question is fairly simple, pretty well just tables full
> > of data, no stored procs...
> > suggestions?
> > TIA