Mirroring Client

Hello,
When a failover occurs can clients be automatically redirected to the active
instance of a db or does this have to be done with code?
Thanks in advance!Mark,
When the database failover occurs your sessions will be disconnected. You
need to update your application to automatically fail over when this database
failover occurs.
Here is how you can do it.
Implementing Application Failover with Database Mirroring
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/implappfailover.mspx
Hope this helps,
Ben Nevarez
"Mark" wrote:
> Hello,
> When a failover occurs can clients be automatically redirected to the active
> instance of a db or does this have to be done with code?
> Thanks in advance!
>|||When you have a session connected to a database (principal) and the database
fails over to the mirror, your session will be disconnected. You can open a
new session and it will now be connected to the new principal (that was the
mirror before). This requires no application changes and perhaps only will
need the failover partner clause on the connection string.
But if you need application automatic failover you can implement the retry
logic described in the best practices article I mentioned here.
Hope this helps,
Ben Nevarez
"Ben Nevarez" wrote:
> Mark,
> When the database failover occurs your sessions will be disconnected. You
> need to update your application to automatically fail over when this database
> failover occurs.
> Here is how you can do it.
> Implementing Application Failover with Database Mirroring
> http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/implappfailover.mspx
> Hope this helps,
> Ben Nevarez
>
>
> "Mark" wrote:
> > Hello,
> >
> > When a failover occurs can clients be automatically redirected to the active
> > instance of a db or does this have to be done with code?
> >
> > Thanks in advance!
> >

Migration Of MSSQL instance along with security permissions

Hi All,

This is the scenario. Basically i work for a web hosting company now we have taken over control of a competitor and would like to migrate there existing data to our own MSSQL server's in order to integrate them into our automatic system etc etc ...

The current system is running MSSQL7.

The system been copied to is MSSQL2K.

Objectives:

Retain all security accounts listed on the MSSQL7 system and use them on the MSSQL2K system. This includes all the logins that use standard MSSQL login's. (Reason : To ensure that all the customers ASP pages work after the DB's have been copied.)
Backup all the databases on the MSSQL7 and restore them to the MSSQL2K system. Unfortunately system is running on a different network with firewall's etc in between. What type of maintenance plan and how should i implement the requirement to keep all the login account's?
Any help greatly appreciated......
thxone of the option can be like take all backups on either hdd or tape then connect it to ur server copy it from previous one to new one.
to copy all login info etc u can write a script if u need the script i can send u next time (this will take the info to a cursor and one by one it wil update.)
as far as sql 7 database schema and 2k schema is concerned i dont think it will be a problem.
this is an intersting case pl update me|||Hi ranjan apologies for not replying sooner (did not know if anyone had replied). I agree when u state that u dont think either that the difference between porting to 2000 is going to cause an issue. I have restored all the databases now but am in need of a little help / inspiration on how to port over the login names. Perhaps you can help or have a script that performs this task. Regards the script u have for updating i presume its independent to the current logins that are on the SQL2K system at present. How is this done?

Migration from Oracle 7.34 to SQL 2000

I'm attempting to move a database which currently exists on an old Oracle
7.34 instance and tried to use Data Import via DTS to SQL 2000.
The Oracle database consists of views, indexes,packages,triggers as well as
tables structures. I tried DTS using both the ODBC and OLE for Oracle and
only tables and data came over correctly.
Views it appears were converted into tables. Indexes not at all.
I'm using the Oracle 9.2 client on my workstation.
Any ideas on how I might be able to convert this database over from Oracle?
thks
You'll have to move the code, views, etc manually
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Jack Snow" <mrbrew5510@.hotmail.com> wrote in message
news:tea_c.4190$lv3.2047604@.news4.srv.hcvlny.cv.ne t...
> I'm attempting to move a database which currently exists on an old Oracle
> 7.34 instance and tried to use Data Import via DTS to SQL 2000.
> The Oracle database consists of views, indexes,packages,triggers as well
as
> tables structures. I tried DTS using both the ODBC and OLE for Oracle and
> only tables and data came over correctly.
> Views it appears were converted into tables. Indexes not at all.
> I'm using the Oracle 9.2 client on my workstation.
> Any ideas on how I might be able to convert this database over from
Oracle?
>
> thks
>

Migration from Oracle 7.34 to SQL 2000

I'm attempting to move a database which currently exists on an old Oracle
7.34 instance and tried to use Data Import via DTS to SQL 2000.
The Oracle database consists of views, indexes,packages,triggers as well as
tables structures. I tried DTS using both the ODBC and OLE for Oracle and
only tables and data came over correctly.
Views it appears were converted into tables. Indexes not at all.
I'm using the Oracle 9.2 client on my workstation.
Any ideas on how I might be able to convert this database over from Oracle?
thksYou'll have to move the code, views, etc manually
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Jack Snow" <mrbrew5510@.hotmail.com> wrote in message
news:tea_c.4190$lv3.2047604@.news4.srv.hcvlny.cv.net...
> I'm attempting to move a database which currently exists on an old Oracle
> 7.34 instance and tried to use Data Import via DTS to SQL 2000.
> The Oracle database consists of views, indexes,packages,triggers as well
as
> tables structures. I tried DTS using both the ODBC and OLE for Oracle and
> only tables and data came over correctly.
> Views it appears were converted into tables. Indexes not at all.
> I'm using the Oracle 9.2 client on my workstation.
> Any ideas on how I might be able to convert this database over from
Oracle?
>
> thks
>

Migration data from SQL 7.0 to SQL 2005

I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
on to of the existing 7.0 instance and perfrom a full system upgrade. What I
don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
import the SQL 7.0 database and convert it for use inder 2005? I don't want
to burn my tracks by upgrdaing the existing server. If the install goes bad,
I can't fall back if nercessary. The books online for the lates preview don't
indicate the abaility migrate data fromj 7.0 as a stand alone process
sepparate from a full upgrade.
You should be able to detach the database from SQL Server 7.0 and attach it
to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
procedures. For more information about upgrading databases from previous
versions to SQL Server 2005, see SQL Server 2005 Books Online.
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> I know that sQL 2005 support upgrading a SQL 7.0 database if you install
it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
want
> to burn my tracks by upgrdaing the existing server. If the install goes
bad,
> I can't fall back if nercessary. The books online for the lates preview
don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.
|||I have read the books online and I don't get the impression that you can
either directly attach a 7.0 database or alternatively, use the "copy
database wizard". Attempts to directly attach a SQL 7.0 database have failed
when initiated by scripts generated using the new scripting wizard. The “copy
database wizard” clearly states in its opening text that it can only be used
when copying SQL 2000 or 2005 data. There is no mention of copying SQL 7.0
data at all.
The books online recommend not using “sp_attach_db” command since it will no
longer be supported in the future. They suggest using the “CREAT DATABASE”
command in its place which is what the script generated by the wizard used.
In eaither case, the action failed.
"Narayana Vyas Kondreddi" wrote:

> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||OK, I got it to work. For some reason, scheduling the script to run via the
agent causes it to fail when executed. However, when I copied the script to
the query analyzer and executed it from there, it worked correctly.
"Narayana Vyas Kondreddi" wrote:

> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||For additional help with upgrading to SQL Server 2005 from earlier versions
of SQL Server, you may be interested in the SQL Server 2005 Upgrade Advisor:
http://www.microsoft.com/downloads/d...DisplayLang=en
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
>I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> I can't fall back if nercessary. The books online for the lates preview
> don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.

Migration data from SQL 7.0 to SQL 2005

I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
on to of the existing 7.0 instance and perfrom a full system upgrade. What I
don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
import the SQL 7.0 database and convert it for use inder 2005? I don't want
to burn my tracks by upgrdaing the existing server. If the install goes bad,
I can't fall back if nercessary. The books online for the lates preview don't
indicate the abaility migrate data fromj 7.0 as a stand alone process
sepparate from a full upgrade.You should be able to detach the database from SQL Server 7.0 and attach it
to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
procedures. For more information about upgrading databases from previous
versions to SQL Server 2005, see SQL Server 2005 Books Online.
--
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> I know that sQL 2005 support upgrading a SQL 7.0 database if you install
it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
want
> to burn my tracks by upgrdaing the existing server. If the install goes
bad,
> I can't fall back if nercessary. The books online for the lates preview
don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.|||I have read the books online and I don't get the impression that you can
either directly attach a 7.0 database or alternatively, use the "copy
database wizard". Attempts to directly attach a SQL 7.0 database have failed
when initiated by scripts generated using the new scripting wizard. The â'copy
database wizardâ' clearly states in its opening text that it can only be used
when copying SQL 2000 or 2005 data. There is no mention of copying SQL 7.0
data at all.
The books online recommend not using â'sp_attach_dbâ' command since it will no
longer be supported in the future. They suggest using the â'CREAT DATABASEâ'
command in its place which is what the script generated by the wizard used.
In eaither case, the action failed.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> > I know that sQL 2005 support upgrading a SQL 7.0 database if you install
> it
> > on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> > don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> > import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> > to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> > I can't fall back if nercessary. The books online for the lates preview
> don't
> > indicate the abaility migrate data fromj 7.0 as a stand alone process
> > sepparate from a full upgrade.
>
>|||OK, I got it to work. For some reason, scheduling the script to run via the
agent causes it to fail when executed. However, when I copied the script to
the query analyzer and executed it from there, it worked correctly.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> > I know that sQL 2005 support upgrading a SQL 7.0 database if you install
> it
> > on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> > don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> > import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> > to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> > I can't fall back if nercessary. The books online for the lates preview
> don't
> > indicate the abaility migrate data fromj 7.0 as a stand alone process
> > sepparate from a full upgrade.
>
>|||For additional help with upgrading to SQL Server 2005 from earlier versions
of SQL Server, you may be interested in the SQL Server 2005 Upgrade Advisor:
http://www.microsoft.com/downloads/details.aspx?FamilyID=cf28daf9-182e-4ac2-8e88-f2e936558bf2&DisplayLang=en
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
>I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> I can't fall back if nercessary. The books online for the lates preview
> don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.

Migration data from SQL 7.0 to SQL 2005

I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
on to of the existing 7.0 instance and perfrom a full system upgrade. What I
don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
import the SQL 7.0 database and convert it for use inder 2005? I don't want
to burn my tracks by upgrdaing the existing server. If the install goes bad,
I can't fall back if nercessary. The books online for the lates preview don'
t
indicate the abaility migrate data fromj 7.0 as a stand alone process
sepparate from a full upgrade.You should be able to detach the database from SQL Server 7.0 and attach it
to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
procedures. For more information about upgrading databases from previous
versions to SQL Server 2005, see SQL Server 2005 Books Online.
--
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> I know that sQL 2005 support upgrading a SQL 7.0 database if you install
it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
want
> to burn my tracks by upgrdaing the existing server. If the install goes
bad,
> I can't fall back if nercessary. The books online for the lates preview
don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.|||I have read the books online and I don't get the impression that you can
either directly attach a 7.0 database or alternatively, use the "copy
database wizard". Attempts to directly attach a SQL 7.0 database have failed
when initiated by scripts generated using the new scripting wizard. The “c
opy
database wizard” clearly states in its opening text that it can only be us
ed
when copying SQL 2000 or 2005 data. There is no mention of copying SQL 7.0
data at all.
The books online recommend not using “sp_attach_db” command since it wil
l no
longer be supported in the future. They suggest using the “CREAT DATABASE
command in its place which is what the script generated by the wizard used.
In eaither case, the action failed.
"Narayana Vyas Kondreddi" wrote:

> You should be able to detach the database from SQL Server 7.0 and attach i
t
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>|||OK, I got it to work. For some reason, scheduling the script to run via the
agent causes it to fail when executed. However, when I copied the script to
the query analyzer and executed it from there, it worked correctly.
"Narayana Vyas Kondreddi" wrote:

> You should be able to detach the database from SQL Server 7.0 and attach i
t
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>|||For additional help with upgrading to SQL Server 2005 from earlier versions
of SQL Server, you may be interested in the SQL Server 2005 Upgrade Advisor:
http://www.microsoft.com/downloads/...&DisplayLang=en
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
>I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> I can't fall back if nercessary. The books online for the lates preview
> don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.

Migrating to 2005, need advice

Help. I have been tasked with upgrading a 2000 instance to 2005.

I have actually done this before, but it was a long time ago, and I
didn't do it alone. Now, the sitation is little different, and I need
to know the EXACT steps to take.

Does anyone have a FAQ or link that outlines migration steps? I found
one on sql server central, but it isn't very detailed.

One of the important things I need to know is, how do I create a
rollback plan if I am upgrading from 2000 to 2005 on the same server
(instance)?

Also, why can't I seem to find a comprehensive list of TO DO's when
upgrading? Doesn't microsoft provide this? You would think so. I will
run upgrade advisor first, but isn't there also documentation
somewhere?

I seem to recall lots of permissions issues that arose with 2005.

HELP

Thanks(tootsuite@.gmail.com) writes:

Quote:

Originally Posted by

Help. I have been tasked with upgrading a 2000 instance to 2005.
>
I have actually done this before, but it was a long time ago, and I
didn't do it alone. Now, the sitation is little different, and I need
to know the EXACT steps to take.
>
Does anyone have a FAQ or link that outlines migration steps? I found
one on sql server central, but it isn't very detailed.
>
One of the important things I need to know is, how do I create a
rollback plan if I am upgrading from 2000 to 2005 on the same server
(instance)?

It's certainly not a bad idea to install a second instance on the
same machine, and the migrate by BACKUP/RESTORE. This is great if
you run into performance issues and want ot compare query plans. The
drawback if you install a new instance is that a lot of clients will
be affected.

A second alternative is to install SQL 2005 on a new machine, and when
the install has completed, you change the names and IP-address of the
machines, so that the clients can't tell the difference. Of course,
this means that you need to shop for hardware.

This makes it sounds like an in-place upgrade should be avoided at
all cost, but it's not that bad. But I will have to admit that I
have never done one, nor do I plan to. If you have to go that path,
I recommend that you start with installing a second instance of SQL 2000,
and restore databases on this instance. Yes, I still think it is a
good idea to keep SQL 2000 for reference for a while.

In any case, you should first set up a test environment, so that you
can test doing in-place upgrades, and at least conduct some testing
of your applications.

Here is a short list of must-do:

1) Change the compatibility level of all databases to 90. If too many
things break, you may to move back to 90, but be optimistic.

2) Run sp_updatestats on all databases. Old statistics are voided by
the upgrade.

3) If you move databases from another server, you need to rematch
users with logins. (This applies even if you don't make upgrades.)
This includes setting the database owner, if the owner is not sa.

There a few things that can break. Here is a list of the most
probable cases:

* Old-style outer-join, *= and =*. Caught by the Upgrade Advisor,
and can be avoided with compat level 80.

* WITH is now required for hints with more than one work. Caught by the
Upgrade Advisor, and can be avoided with compat level 80.

* Views that uses SELECT TOP 100 PRECENT ORDER BY. In SQL 2000 a
SELECT without ORDER BY from this view seemed to get the order of
the ORDER BY in the view definition. This was mere chance, and it
does not happen that often on SQL 2005. This is *not* caught by
the Upgrade Advisor, as far as I know, and you cannot save the
day with compat level 80.

* Passwords are now always case-sensitive.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On Feb 12, 5:52 am, tootsu...@.gmail.com wrote:

Quote:

Originally Posted by

Help. I have been tasked with upgrading a 2000 instance to 2005.
>
I have actually done this before, but it was a long time ago, and I
didn't do it alone. Now, the sitation is little different, and I need
to know the EXACT steps to take.
>
Does anyone have a FAQ or link that outlines migration steps? I found
one on sql server central, but it isn't very detailed.
>
One of the important things I need to know is, how do I create a
rollback plan if I am upgrading from 2000 to 2005 on the same server
(instance)?
>
Also, why can't I seem to find a comprehensive list of TO DO's when
upgrading? Doesn't microsoft provide this? You would think so. I will
run upgrade advisor first, but isn't there also documentation
somewhere?
>
I seem to recall lots of permissions issues that arose with 2005.
>
HELP
>
Thanks

The only reliable way to catch all issues is to script out your SQL
2000 databases and then rebuild them on a SQL 2005 database with
compatibility level 90. This method is much better than using the
Upgrade Advisor alone.

For tools that make this process easy please visit www.dbghost.com
Regards,

Malcolm|||Mork69 (mleach@.bigfoot.com) writes:

Quote:

Originally Posted by

The only reliable way to catch all issues is to script out your SQL
2000 databases and then rebuild them on a SQL 2005 database with
compatibility level 90. This method is much better than using the
Upgrade Advisor alone.

I agree that running the scripts is a good idea, because you can
catch all compilation errors.

However, for the actual migration, I strongly recommend to use
backup/restore or detach/attach. Scripting is a more complex and a
process more prone to errors.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On Feb 13, 10:10 pm, Erland Sommarskog <esq...@.sommarskog.sewrote:

Quote:

Originally Posted by

Mork69 (mle...@.bigfoot.com) writes:

Quote:

Originally Posted by

The only reliable way to catch all issues is to script out your SQL
2000 databases and then rebuild them on a SQL 2005 database with
compatibility level 90. This method is much better than using the
Upgrade Advisor alone.

>
I agree that running the scripts is a good idea, because you can
catch all compilation errors.
>
However, for the actual migration, I strongly recommend to use
backup/restore or detach/attach. Scripting is a more complex and a
process more prone to errors.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

In fact, if both approaches are used then the migration should be
perfect. i.e. You script out and build in order to highlight and fix
all the problems. If you keep the scripts for the objects that were
fixed then you can do the detach/attach and then recreate them.