Copy objects with DTS Import/Export Wizard?

Has the functionality of copying objects using the DTS Import/Export Wizard been removed in SQL Server 2005?

MSDN says this about the wizard:

"With the DTS Import/Export Wizard, you can transfer database objects such as indexes, views, roles, stored procedures, and referential integrity constraints. For more information, see Copy SQL Server Objects Task."

But the "for more imformation" link describes adding a task to a DTS package to copy an object, not how to use the wizard to copy objects.

It's been awhile since I've used SQL Server 2000, but as I recall it was possible to copy objects as well as data using the DTS Import/Export Wizard.

Thanks,

Ron

DTS has been enhanced to SSIS(Integration Services) in SQL 2005, so in this case you can use SSIS package to perform that copy SQL Server objects tasks which is similar to the copying the database objects.|||

You have a few options:

Copy Database Wizard:
Use this if you want to copy an entire database.

Right-click on a database in Management Studio, go to "Tasks", and choose "Copy Database...".|||

I also share in their frustrations... When you only have a few objects, in this case tables to transfer; you have very little options in the SQL2005 Import/Export wizard as compared to the SQL2000 DTS (Import/Export) wizard. Copy Database is out of the question for this scenario.

My problem lies in the fact that the SQL2005 Import/Export wizard does not create the indexes and keys when the table needs to be created in the target database, even if the source schema exists on the target database. Is there any way around this without pre-creating the target tables from scripts generated on the source DB? Seems that this manual step should be built into the wizard? Ay suggestions? We are running SP2 for SQL 2005.

There are suggestions that SSIS can be used, thats fine, but given the entirely different interface as compared to DTS, I don't have the time to deal with that when the wizard should be able to do this in a few minutes.

|||That option is fine for SQL2000/2005 to SQL2005, but is there any option to copy to SQL2000?|||I am getting very frustrated, for two days now I've been trying to work out how to copy a database (SQL express version) to my ISP which has the full MS 2005 server. I keep losing keys, stored procedures etc. When you right click on the database as you say and click on tasks there's no copy database there.|||Yey! now I get to spend 2 hours with ssis doing what used to take 2 minutes with dts import wizard.|||

I now use MS Database Publishing wizard which attaches to Database Explorer in Microsoft Developer Express. It works better than DTS Import/Export as I do not lose keys and can copy all object in the database. Great for making backups too.

Copy objects with DTS Import/Export Wizard?

Has the functionality of copying objects using the DTS Import/Export Wizard been removed in SQL Server 2005?

MSDN says this about the wizard:

"With the DTS Import/Export Wizard, you can transfer database objects such as indexes, views, roles, stored procedures, and referential integrity constraints. For more information, see Copy SQL Server Objects Task."

But the "for more imformation" link describes adding a task to a DTS package to copy an object, not how to use the wizard to copy objects.

It's been awhile since I've used SQL Server 2000, but as I recall it was possible to copy objects as well as data using the DTS Import/Export Wizard.

Thanks,

Ron

DTS has been enhanced to SSIS(Integration Services) in SQL 2005, so in this case you can use SSIS package to perform that copy SQL Server objects tasks which is similar to the copying the database objects.|||

You have a few options:

Copy Database Wizard:
Use this if you want to copy an entire database.

Right-click on a database in Management Studio, go to "Tasks", and choose "Copy Database...".|||

I also share in their frustrations... When you only have a few objects, in this case tables to transfer; you have very little options in the SQL2005 Import/Export wizard as compared to the SQL2000 DTS (Import/Export) wizard. Copy Database is out of the question for this scenario.

My problem lies in the fact that the SQL2005 Import/Export wizard does not create the indexes and keys when the table needs to be created in the target database, even if the source schema exists on the target database. Is there any way around this without pre-creating the target tables from scripts generated on the source DB? Seems that this manual step should be built into the wizard? Ay suggestions? We are running SP2 for SQL 2005.

There are suggestions that SSIS can be used, thats fine, but given the entirely different interface as compared to DTS, I don't have the time to deal with that when the wizard should be able to do this in a few minutes.

|||That option is fine for SQL2000/2005 to SQL2005, but is there any option to copy to SQL2000?|||I am getting very frustrated, for two days now I've been trying to work out how to copy a database (SQL express version) to my ISP which has the full MS 2005 server. I keep losing keys, stored procedures etc. When you right click on the database as you say and click on tasks there's no copy database there.|||Yey! now I get to spend 2 hours with ssis doing what used to take 2 minutes with dts import wizard.|||

I now use MS Database Publishing wizard which attaches to Database Explorer in Microsoft Developer Express. It works better than DTS Import/Export as I do not lose keys and can copy all object in the database. Great for making backups too.

sqlsql

Copy objects with DTS Import/Export Wizard?

Has the functionality of copying objects using the DTS Import/Export Wizard been removed in SQL Server 2005?

MSDN says this about the wizard:

"With the DTS Import/Export Wizard, you can transfer database objects such as indexes, views, roles, stored procedures, and referential integrity constraints. For more information, see Copy SQL Server Objects Task."

But the "for more imformation" link describes adding a task to a DTS package to copy an object, not how to use the wizard to copy objects.

It's been awhile since I've used SQL Server 2000, but as I recall it was possible to copy objects as well as data using the DTS Import/Export Wizard.

Thanks,

Ron

DTS has been enhanced to SSIS(Integration Services) in SQL 2005, so in this case you can use SSIS package to perform that copy SQL Server objects tasks which is similar to the copying the database objects.|||

You have a few options:

Copy Database Wizard:
Use this if you want to copy an entire database.

Right-click on a database in Management Studio, go to "Tasks", and choose "Copy Database...".|||

I also share in their frustrations... When you only have a few objects, in this case tables to transfer; you have very little options in the SQL2005 Import/Export wizard as compared to the SQL2000 DTS (Import/Export) wizard. Copy Database is out of the question for this scenario.

My problem lies in the fact that the SQL2005 Import/Export wizard does not create the indexes and keys when the table needs to be created in the target database, even if the source schema exists on the target database. Is there any way around this without pre-creating the target tables from scripts generated on the source DB? Seems that this manual step should be built into the wizard? Ay suggestions? We are running SP2 for SQL 2005.

There are suggestions that SSIS can be used, thats fine, but given the entirely different interface as compared to DTS, I don't have the time to deal with that when the wizard should be able to do this in a few minutes.

|||That option is fine for SQL2000/2005 to SQL2005, but is there any option to copy to SQL2000?|||I am getting very frustrated, for two days now I've been trying to work out how to copy a database (SQL express version) to my ISP which has the full MS 2005 server. I keep losing keys, stored procedures etc. When you right click on the database as you say and click on tasks there's no copy database there.|||Yey! now I get to spend 2 hours with ssis doing what used to take 2 minutes with dts import wizard.|||

I now use MS Database Publishing wizard which attaches to Database Explorer in Microsoft Developer Express. It works better than DTS Import/Export as I do not lose keys and can copy all object in the database. Great for making backups too.

Copy objects with DTS Import/Export Wizard?

Has the functionality of copying objects using the DTS Import/Export Wizard been removed in SQL Server 2005?

MSDN says this about the wizard:

"With the DTS Import/Export Wizard, you can transfer database objects such as indexes, views, roles, stored procedures, and referential integrity constraints. For more information, see Copy SQL Server Objects Task."

But the "for more imformation" link describes adding a task to a DTS package to copy an object, not how to use the wizard to copy objects.

It's been awhile since I've used SQL Server 2000, but as I recall it was possible to copy objects as well as data using the DTS Import/Export Wizard.

Thanks,

Ron

DTS has been enhanced to SSIS(Integration Services) in SQL 2005, so in this case you can use SSIS package to perform that copy SQL Server objects tasks which is similar to the copying the database objects.|||

You have a few options:

Copy Database Wizard:
Use this if you want to copy an entire database.

Right-click on a database in Management Studio, go to "Tasks", and choose "Copy Database...".|||

I also share in their frustrations... When you only have a few objects, in this case tables to transfer; you have very little options in the SQL2005 Import/Export wizard as compared to the SQL2000 DTS (Import/Export) wizard. Copy Database is out of the question for this scenario.

My problem lies in the fact that the SQL2005 Import/Export wizard does not create the indexes and keys when the table needs to be created in the target database, even if the source schema exists on the target database. Is there any way around this without pre-creating the target tables from scripts generated on the source DB? Seems that this manual step should be built into the wizard? Ay suggestions? We are running SP2 for SQL 2005.

There are suggestions that SSIS can be used, thats fine, but given the entirely different interface as compared to DTS, I don't have the time to deal with that when the wizard should be able to do this in a few minutes.

|||That option is fine for SQL2000/2005 to SQL2005, but is there any option to copy to SQL2000?|||I am getting very frustrated, for two days now I've been trying to work out how to copy a database (SQL express version) to my ISP which has the full MS 2005 server. I keep losing keys, stored procedures etc. When you right click on the database as you say and click on tasks there's no copy database there.|||Yey! now I get to spend 2 hours with ssis doing what used to take 2 minutes with dts import wizard.|||

I now use MS Database Publishing wizard which attaches to Database Explorer in Microsoft Developer Express. It works better than DTS Import/Export as I do not lose keys and can copy all object in the database. Great for making backups too.

copy many ssis packages between servers

Hi.
Is there any simple way of copying all of the ssis packages between two
servers?
I have just installed sql 2005 on a new, better equipped machine and I have
to move there all the data. Including ssis of course. There are about 40-50
packages to do (stored in the database, not in filesystem) and I hope there
is a better way than just to import packages (one by one) to a text file
and export them to another server.
BTW, I'm going to copy the job definitions as well, there are about 20 jobs
defined on the server, is there any handy way of doing this? Any hints?
PLTry backing up and restoring MSDB and changing the appropriate fields.
We do this with jobs every week to keep 2 servers in sync and this is what
we use to bring the jobs up to date. I would imagine that it could be just
as easy for SSIS packages, though I haven't tried it officially.
UPDATE sysjobs
SET originating_server = 'MyServer'
So just run that on the new server once you have MSDB restored on there and
you should be OK. And just check the SSIS tables to discover similar entrie
s
that may need to be changed.
"Piotr Lipski" wrote:

> Hi.
> Is there any simple way of copying all of the ssis packages between two
> servers?
> I have just installed sql 2005 on a new, better equipped machine and I hav
e
> to move there all the data. Including ssis of course. There are about 40-5
0
> packages to do (stored in the database, not in filesystem) and I hope ther
e
> is a better way than just to import packages (one by one) to a text file
> and export them to another server.
> BTW, I'm going to copy the job definitions as well, there are about 20 job
s
> defined on the server, is there any handy way of doing this? Any hints?
> --
> PL
>|||Sean McCown wrote:
> Try backing up and restoring MSDB and changing the appropriate fields.
> We do this with jobs every week to keep 2 servers in sync and this is what
> we use to bring the jobs up to date. I would imagine that it could be jus
t
> as easy for SSIS packages, though I haven't tried it officially.
> UPDATE sysjobs
> SET originating_server = 'MyServer'
> So just run that on the new server once you have MSDB restored on there an
d
> you should be OK. And just check the SSIS tables to discover similar entr
ies
> that may need to be changed.
Right. But how to restore the msdb database? When I try to do it from
SMS (right click on database -> tasks -> restore) I get failure message
"Exclusive access could not be obtained because the database is in
use.", which makes sense but does not resolve the problem. There is also
no option to go off-line or detach for that database.
Should I just replace the msdb datafiles (mdf/ldf) with the ones from
'old' server?
PL|||OK, there are a couple things here...
first, to restore MSDB just startup SQL with -T3608 and -m. 3608 prevents
startup of all system DBs except master. -m is single-user mode. So you
should now be able to restore MSDB with no problem. If you're doing it from
the command line, then use -c.
Second, You can always just setup a linked server and copy the raw data over
without restoring.
Good luck.
"Piotr Lipski" wrote:

> Sean McCown wrote:
> Right. But how to restore the msdb database? When I try to do it from
> SMS (right click on database -> tasks -> restore) I get failure message
> "Exclusive access could not be obtained because the database is in
> use.", which makes sense but does not resolve the problem. There is also
> no option to go off-line or detach for that database.
> Should I just replace the msdb datafiles (mdf/ldf) with the ones from
> 'old' server?
> --
> PL
>

copy many ssis packages between servers

Hi.
Is there any simple way of copying all of the ssis packages between two
servers?
I have just installed sql 2005 on a new, better equipped machine and I have
to move there all the data. Including ssis of course. There are about 40-50
packages to do (stored in the database, not in filesystem) and I hope there
is a better way than just to import packages (one by one) to a text file
and export them to another server.
BTW, I'm going to copy the job definitions as well, there are about 20 jobs
defined on the server, is there any handy way of doing this? Any hints?
--
PLTry backing up and restoring MSDB and changing the appropriate fields.
We do this with jobs every week to keep 2 servers in sync and this is what
we use to bring the jobs up to date. I would imagine that it could be just
as easy for SSIS packages, though I haven't tried it officially.
UPDATE sysjobs
SET originating_server = 'MyServer'
So just run that on the new server once you have MSDB restored on there and
you should be OK. And just check the SSIS tables to discover similar entries
that may need to be changed.
"Piotr Lipski" wrote:
> Hi.
> Is there any simple way of copying all of the ssis packages between two
> servers?
> I have just installed sql 2005 on a new, better equipped machine and I have
> to move there all the data. Including ssis of course. There are about 40-50
> packages to do (stored in the database, not in filesystem) and I hope there
> is a better way than just to import packages (one by one) to a text file
> and export them to another server.
> BTW, I'm going to copy the job definitions as well, there are about 20 jobs
> defined on the server, is there any handy way of doing this? Any hints?
> --
> PL
>|||Sean McCown wrote:
> Try backing up and restoring MSDB and changing the appropriate fields.
> We do this with jobs every week to keep 2 servers in sync and this is what
> we use to bring the jobs up to date. I would imagine that it could be just
> as easy for SSIS packages, though I haven't tried it officially.
> UPDATE sysjobs
> SET originating_server = 'MyServer'
> So just run that on the new server once you have MSDB restored on there and
> you should be OK. And just check the SSIS tables to discover similar entries
> that may need to be changed.
Right. But how to restore the msdb database? When I try to do it from
SMS (right click on database -> tasks -> restore) I get failure message
"Exclusive access could not be obtained because the database is in
use.", which makes sense but does not resolve the problem. There is also
no option to go off-line or detach for that database.
Should I just replace the msdb datafiles (mdf/ldf) with the ones from
'old' server?
--
PL|||OK, there are a couple things here...
first, to restore MSDB just startup SQL with -T3608 and -m. 3608 prevents
startup of all system DBs except master. -m is single-user mode. So you
should now be able to restore MSDB with no problem. If you're doing it from
the command line, then use -c.
Second, You can always just setup a linked server and copy the raw data over
without restoring.
Good luck.
"Piotr Lipski" wrote:
> Sean McCown wrote:
> > Try backing up and restoring MSDB and changing the appropriate fields.
> > We do this with jobs every week to keep 2 servers in sync and this is what
> > we use to bring the jobs up to date. I would imagine that it could be just
> > as easy for SSIS packages, though I haven't tried it officially.
> >
> > UPDATE sysjobs
> > SET originating_server = 'MyServer'
> >
> > So just run that on the new server once you have MSDB restored on there and
> > you should be OK. And just check the SSIS tables to discover similar entries
> > that may need to be changed.
> Right. But how to restore the msdb database? When I try to do it from
> SMS (right click on database -> tasks -> restore) I get failure message
> "Exclusive access could not be obtained because the database is in
> use.", which makes sense but does not resolve the problem. There is also
> no option to go off-line or detach for that database.
> Should I just replace the msdb datafiles (mdf/ldf) with the ones from
> 'old' server?
> --
> PL
>

copy many ssis packages between servers

Hi.
Is there any simple way of copying all of the ssis packages between two
servers?
I have just installed sql 2005 on a new, better equipped machine and I have
to move there all the data. Including ssis of course. There are about 40-50
packages to do (stored in the database, not in filesystem) and I hope there
is a better way than just to import packages (one by one) to a text file
and export them to another server.
BTW, I'm going to copy the job definitions as well, there are about 20 jobs
defined on the server, is there any handy way of doing this? Any hints?
PL
Try backing up and restoring MSDB and changing the appropriate fields.
We do this with jobs every week to keep 2 servers in sync and this is what
we use to bring the jobs up to date. I would imagine that it could be just
as easy for SSIS packages, though I haven't tried it officially.
UPDATE sysjobs
SET originating_server = 'MyServer'
So just run that on the new server once you have MSDB restored on there and
you should be OK. And just check the SSIS tables to discover similar entries
that may need to be changed.
"Piotr Lipski" wrote:

> Hi.
> Is there any simple way of copying all of the ssis packages between two
> servers?
> I have just installed sql 2005 on a new, better equipped machine and I have
> to move there all the data. Including ssis of course. There are about 40-50
> packages to do (stored in the database, not in filesystem) and I hope there
> is a better way than just to import packages (one by one) to a text file
> and export them to another server.
> BTW, I'm going to copy the job definitions as well, there are about 20 jobs
> defined on the server, is there any handy way of doing this? Any hints?
> --
> PL
>
|||Sean McCown wrote:
> Try backing up and restoring MSDB and changing the appropriate fields.
> We do this with jobs every week to keep 2 servers in sync and this is what
> we use to bring the jobs up to date. I would imagine that it could be just
> as easy for SSIS packages, though I haven't tried it officially.
> UPDATE sysjobs
> SET originating_server = 'MyServer'
> So just run that on the new server once you have MSDB restored on there and
> you should be OK. And just check the SSIS tables to discover similar entries
> that may need to be changed.
Right. But how to restore the msdb database? When I try to do it from
SMS (right click on database -> tasks -> restore) I get failure message
"Exclusive access could not be obtained because the database is in
use.", which makes sense but does not resolve the problem. There is also
no option to go off-line or detach for that database.
Should I just replace the msdb datafiles (mdf/ldf) with the ones from
'old' server?
PL
|||OK, there are a couple things here...
first, to restore MSDB just startup SQL with -T3608 and -m. 3608 prevents
startup of all system DBs except master. -m is single-user mode. So you
should now be able to restore MSDB with no problem. If you're doing it from
the command line, then use -c.
Second, You can always just setup a linked server and copy the raw data over
without restoring.
Good luck.
"Piotr Lipski" wrote:

> Sean McCown wrote:
> Right. But how to restore the msdb database? When I try to do it from
> SMS (right click on database -> tasks -> restore) I get failure message
> "Exclusive access could not be obtained because the database is in
> use.", which makes sense but does not resolve the problem. There is also
> no option to go off-line or detach for that database.
> Should I just replace the msdb datafiles (mdf/ldf) with the ones from
> 'old' server?
> --
> PL
>
sqlsql

copy from one table to the other using stored procedure

Hi there,
How to the scripts for copying data in table A to table B using stored procedure?
ThanxINSERT INTO Table_A
SELECT * FROM Table_B|||Hi there,

I got this one prob.............i have to copy from data which consist in the VIEWS section in SQL Server Enterprise Manager.
This views section already contain the script which limit the user to few databases and i need to copy watever display in the view section to a new table in other database.
Thanx|||Hi there...

Maybe this will help:

Select * into Other_db..newTable from Source_db..View

Other_db = the database where the new table should be created
newTable = the name of the new table
Source_db = is the database where you query the view
View = the name of the View

I hope this helps.

Greetz,
Marc,
:)|||thanx

copy db sql7 ->2000 newbie question

Hi,
I have a backup copy of a database in sql 7. I am copying it over to sql
2000 and then restoring it. There are 3 views that show up in both the table
and view section in sql 2000 but they are only in the view section in sql 7.
(sql 7 running on windows 2000 server/sql 2000 on windows 2003 server.) why
is that happening?
Thanks for any help with this. much appreciated!
kak37
On Jun 13, 10:12 am, kak37 <k...@.discussions.microsoft.com> wrote:
> Hi,
> I have a backup copy of a database in sql 7. I am copying it over to sql
> 2000 and then restoring it. There are 3 views that show up in both the table
> and view section in sql 2000 but they are only in the view section in sql 7.
> (sql 7 running on windows 2000 server/sql 2000 on windows 2003 server.) why
> is that happening?
> Thanks for any help with this. much appreciated!
> --
> kak37
Try refresh at databse level (EM) and check again
sqlsql

copy db sql7 ->2000 newbie question

Hi,
I have a backup copy of a database in sql 7. I am copying it over to sql
2000 and then restoring it. There are 3 views that show up in both the table
and view section in sql 2000 but they are only in the view section in sql 7.
(sql 7 running on Windows 2000 server/sql 2000 on windows 2003 server.) why
is that happening?
Thanks for any help with this. much appreciated!
--
kak37On Jun 13, 10:12 am, kak37 <k...@.discussions.microsoft.com> wrote:
> Hi,
> I have a backup copy of a database in sql 7. I am copying it over to sql
> 2000 and then restoring it. There are 3 views that show up in both the tab
le
> and view section in sql 2000 but they are only in the view section in sql
7.
> (sql 7 running on Windows 2000 server/sql 2000 on windows 2003 server.) wh
y
> is that happening?
> Thanks for any help with this. much appreciated!
> --
> kak37
Try refresh at databse level (EM) and check again

copy db sql7 ->2000 newbie question

Hi,
I have a backup copy of a database in sql 7. I am copying it over to sql
2000 and then restoring it. There are 3 views that show up in both the table
and view section in sql 2000 but they are only in the view section in sql 7.
(sql 7 running on windows 2000 server/sql 2000 on windows 2003 server.) why
is that happening?
Thanks for any help with this. much appreciated!
--
kak37On Jun 13, 10:12 am, kak37 <k...@.discussions.microsoft.com> wrote:
> Hi,
> I have a backup copy of a database in sql 7. I am copying it over to sql
> 2000 and then restoring it. There are 3 views that show up in both the table
> and view section in sql 2000 but they are only in the view section in sql 7.
> (sql 7 running on windows 2000 server/sql 2000 on windows 2003 server.) why
> is that happening?
> Thanks for any help with this. much appreciated!
> --
> kak37
Try refresh at databse level (EM) and check again

Copy DB fails (at Create Package step) SQL 2005

Copying a db is an easy task under 2000, but 05...
New install of SQL05 on Windows03R2, the machine is a AD domain controller
(one and only in a test forest), SQL services run under an account with
Domain Admin and built-in\Administrators rights. All components (engine,
Integration services, etc) are installed to an E: volume and all services
run under the SQL-Services account I created. No errors anywhere, creating
a test db is fine.
Using the "Copy Database Wizard" fails at the "Create Package" step no
matter if "detach and attach" or "SQL mgnt object" method is used with the
same error (see below). Just a simple one table test db can not be copied
to the same server using the "copy db wizard" in SQL Server 2005.
It looks like the copy package can not be written to the MSDB. The create
package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I have
tried all kind of things - Giving the SQL-Services account db_owner rights
to MSDB (it should already have this from its sysadmin role and membership
in AD/Domain Admins built-in\admins). If there is something wrong with
using the "SQL Server Agent Service Account" as the Integration Services
Proxy account, I created security credentials and a Agent Proxy - but no
go - the wizard always fails at the create package step.
Please help, what am I missing?
===================================
No description found (Copy Database Wizard)
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveTo SqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.SqlServer.Management.CopyDatabaseWizard. PackageCreator.SavePackage()
A little more investigation revealed that SS Business Intelligence DS will
not save a package to the server (it gets a similar error – see below) and
the maintenance plan designer will not save a plan (it gets a "no description
found" error).
So there must be something seriously wrong with the SQL Server 2005
installation routine.
Maybe the installation failed (without error) because I at first installed
only some components to the E: drive and the rest of the components to the C:
drive. The installation screens are VERY poor in clearly describing what
will be installed where. So after I realized a bunch of components got
installed to C: and that the copy of Visual Studio that comes with SQL server
05 was installed to C: and that this would then FORCE the full version of VS
to C: I completely uninstalled SQL 2005.
I reinstalled all components to E: and then installed the full version of VS
(also to E – all without error.
It is likely that the SQL Server 2005 installation routine is fragile – and
it does not tell you about all errors it encounters. This is in complete
contrast to the SQL Server 2000 bullet proof installation routine.
I will do another complete uninstall of SQL 2005 and reinstall to see if
this helps.
Note, others have also reported this problem but not first with the copy db
wizard. Here is one:
http://forums.microsoft.com/MSDN/Sho...29472&SiteID=1
MikeC
Error from create SSIS package:
===================================
No description found (Microsoft Visual Studio)
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveTo SqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.DataTransformationServices.Controls.Pack ageLocationControl.SavePackage(Package package)
at
Microsoft.DataTransformationServices.Design.Contro ls.PackageSaveCopyForm.PackageSaveCopyForm_FormClo sing(Object sender, FormClosingEventArgs e)
"MikeC" wrote:

> Copying a db is an easy task under 2000, but 05...
> New install of SQL05 on Windows03R2, the machine is a AD domain controller
> (one and only in a test forest), SQL services run under an account with
> Domain Admin and built-in\Administrators rights. All components (engine,
> Integration services, etc) are installed to an E: volume and all services
> run under the SQL-Services account I created. No errors anywhere, creating
> a test db is fine.
> Using the "Copy Database Wizard" fails at the "Create Package" step no
> matter if "detach and attach" or "SQL mgnt object" method is used with the
> same error (see below). Just a simple one table test db can not be copied
> to the same server using the "copy db wizard" in SQL Server 2005.
> It looks like the copy package can not be written to the MSDB. The create
> package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I have
> tried all kind of things - Giving the SQL-Services account db_owner rights
> to MSDB (it should already have this from its sysadmin role and membership
> in AD/Domain Admins built-in\admins). If there is something wrong with
> using the "SQL Server Agent Service Account" as the Integration Services
> Proxy account, I created security credentials and a Agent Proxy - but no
> go - the wizard always fails at the create package step.
> Please help, what am I missing?
>
> ===================================
> No description found (Copy Database Wizard)
> --
> Program Location:
> at Microsoft.SqlServer.Dts.Runtime.Application.SaveTo SqlServerAs(Package
> package, IDTSEvents events, String packagePath, String serverName, String
> serverUserName, String serverPassword)
> at
> Microsoft.SqlServer.Management.CopyDatabaseWizard. PackageCreator.SavePackage()
>
>
|||I completely uninstalled SQL Server 2005 and all components - AGAIN.
This time, I deleted all remnants of SQL from the registry and file system -
SQL 2005 uninstall apparently is not as good as the SQL 2000 uninstall...
I reinstalled all components - and now saving packages works, including the
db copy wizard. Why? SQL 2005 install must have an intermittent bug or
something…
Now, have noticed a small bug with service status display, but it is minor.
When will we see SQL 2005 service pack one?
MikeC
|||The failure to create a package on Win03R2/SQL05 is back!
This time, SSIS package saving worked fine for a while. I copied a few
development dbs over to 2005, then went away and did some other work on
SharePoint Services setup.
The server was rebooted and I ran the SQL setup - only to the point of
looking at what was installed - oddly the complete list of installed
components in setup is un-checked. I was looking for the SQL Server Mobile
components - they are not installed and I did not install them.
Anyway the problem is back. So it it not really an install problem. More
trouble-shooting is in order - the absolutely minimal error information
provided does not make it easy.
Have you seen this problem? Help!
MikeC
|||It looks like reinstalling VS05pro after installing SQL05dev on Win03R2
CORRUPTS SQL Server 2005 Integration Services (a package cannot be saved to
server).
If I do the SQL05 install last, I avoid the problem. Now the question is -
what exactly gets corrupted and will this problem reappear when the VS SP1
comes out?
I think SQL Server 2000 was one of the best products that Microsoft created.
The SQL 2000 install was so simple and well behaved. Now, M$ has made SQL
Server into a monsters mess of DCOM linkages and registry bloat. Is it too
much to ask that M$ provide a simple install routine, one that displays a
manifest of files installed, and a list of registry changes? Maybe they are
ashamed of the mass of horrific registry db linkages put in to prop-up their
database “programming” model and want to pretend its not there…
MikeC
|||SQL05 creators - you must be joking - when you choose the Copy Database
""Wizard"" by right clicking on an existing db and then connect to another
server as a *source* you automatically select the local database as a copy
source **IN-ADDITION** to the db that a user needs to select on the remote
server.
In this case the remote db gets copied AND the local db gets copied - two
copies at the same time, so wacky! Just put in a copy db button to fix your
dangerous db copy interface.
MikeC
sqlsql

Copy DB fails (at Create Package step) SQL 2005

Copying a db is an easy task under 2000, but 05...
New install of SQL05 on Windows03R2, the machine is a AD domain controller
(one and only in a test forest), SQL services run under an account with
Domain Admin and built-in\Administrators rights. All components (engine,
Integration services, etc) are installed to an E: volume and all services
run under the SQL-Services account I created. No errors anywhere, creating
a test db is fine.
Using the "Copy Database Wizard" fails at the "Create Package" step no
matter if "detach and attach" or "SQL mgnt object" method is used with the
same error (see below). Just a simple one table test db can not be copied
to the same server using the "copy db wizard" in SQL Server 2005.
It looks like the copy package can not be written to the MSDB. The create
package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I have
tried all kind of things - Giving the SQL-Services account db_owner rights
to MSDB (it should already have this from its sysadmin role and membership
in AD/Domain Admins built-in\admins). If there is something wrong with
using the "SQL Server Agent Service Account" as the Integration Services
Proxy account, I created security credentials and a Agent Proxy - but no
go - the wizard always fails at the create package step.
Please help, what am I missing?
===================================
No description found (Copy Database Wizard)
--
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage
()A little more investigation revealed that SS Business Intelligence DS will
not save a package to the server (it gets a similar error – see below) and
the maintenance plan designer will not save a plan (it gets a "no descriptio
n
found" error).
So there must be something seriously wrong with the SQL Server 2005
installation routine.
Maybe the installation failed (without error) because I at first installed
only some components to the E: drive and the rest of the components to the C
:
drive. The installation screens are VERY poor in clearly describing what
will be installed where. So after I realized a bunch of components got
installed to C: and that the copy of Visual Studio that comes with SQL serve
r
05 was installed to C: and that this would then FORCE the full version of VS
to C: I completely uninstalled SQL 2005.
I reinstalled all components to E: and then installed the full version of VS
(also to E – all without error.
It is likely that the SQL Server 2005 installation routine is fragile – an
d
it does not tell you about all errors it encounters. This is in complete
contrast to the SQL Server 2000 bullet proof installation routine.
I will do another complete uninstall of SQL 2005 and reinstall to see if
this helps.
Note, others have also reported this problem but not first with the copy db
wizard. Here is one:
http://forums.microsoft.com/MSDN/Sh...129472&SiteID=1
MikeC
Error from create SSIS package:
===================================
No description found (Microsoft Visual Studio)
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePac
kage(Package package)
at
Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.Pac
kageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)
"MikeC" wrote:

> Copying a db is an easy task under 2000, but 05...
> New install of SQL05 on Windows03R2, the machine is a AD domain controller
> (one and only in a test forest), SQL services run under an account with
> Domain Admin and built-in\Administrators rights. All components (engine,
> Integration services, etc) are installed to an E: volume and all services
> run under the SQL-Services account I created. No errors anywhere, creatin
g
> a test db is fine.
> Using the "Copy Database Wizard" fails at the "Create Package" step no
> matter if "detach and attach" or "SQL mgnt object" method is used with the
> same error (see below). Just a simple one table test db can not be copied
> to the same server using the "copy db wizard" in SQL Server 2005.
> It looks like the copy package can not be written to the MSDB. The create
> package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I hav
e
> tried all kind of things - Giving the SQL-Services account db_owner rights
> to MSDB (it should already have this from its sysadmin role and membership
> in AD/Domain Admins built-in\admins). If there is something wrong with
> using the "SQL Server Agent Service Account" as the Integration Services
> Proxy account, I created security credentials and a Agent Proxy - but no
> go - the wizard always fails at the create package step.
> Please help, what am I missing?
>
> ===================================
> No description found (Copy Database Wizard)
> --
> Program Location:
> at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Packag
e
> package, IDTSEvents events, String packagePath, String serverName, String
> serverUserName, String serverPassword)
> at
> Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePacka
ge()
>
>|||I completely uninstalled SQL Server 2005 and all components - AGAIN.
This time, I deleted all remnants of SQL from the registry and file system -
SQL 2005 uninstall apparently is not as good as the SQL 2000 uninstall...
I reinstalled all components - and now saving packages works, including the
db copy wizard. Why? SQL 2005 install must have an intermittent bug or
something…
Now, have noticed a small bug with service status display, but it is minor.
When will we see SQL 2005 service pack one?
MikeC|||The failure to create a package on Win03R2/SQL05 is back!
This time, SSIS package saving worked fine for a while. I copied a few
development dbs over to 2005, then went away and did some other work on
SharePoint Services setup.
The server was rebooted and I ran the SQL setup - only to the point of
looking at what was installed - oddly the complete list of installed
components in setup is un-checked. I was looking for the SQL Server Mobile
components - they are not installed and I did not install them.
Anyway the problem is back. So it it not really an install problem. More
trouble-shooting is in order - the absolutely minimal error information
provided does not make it easy.
Have you seen this problem? Help!
MikeC|||It looks like reinstalling VS05pro after installing SQL05dev on Win03R2
CORRUPTS SQL Server 2005 Integration Services (a package cannot be saved to
server).
If I do the SQL05 install last, I avoid the problem. Now the question is -
what exactly gets corrupted and will this problem reappear when the VS SP1
comes out?
I think SQL Server 2000 was one of the best products that Microsoft created.
The SQL 2000 install was so simple and well behaved. Now, M$ has made SQL
Server into a monsters mess of DCOM linkages and registry bloat. Is it too
much to ask that M$ provide a simple install routine, one that displays a
manifest of files installed, and a list of registry changes? Maybe they are
ashamed of the mass of horrific registry db linkages put in to prop-up their
database “programming” model and want to pretend its not there…
MikeC|||SQL05 creators - you must be joking - when you choose the Copy Database
""Wizard"" by right clicking on an existing db and then connect to another
server as a *source* you automatically select the local database as a copy
source **IN-ADDITION** to the db that a user needs to select on the remote
server.
In this case the remote db gets copied AND the local db gets copied - two
copies at the same time, so wacky! Just put in a copy db button to fix your
dangerous db copy interface.
MikeC

Copy DB fails (at Create Package step) SQL 2005

Copying a db is an easy task under 2000, but 05...
New install of SQL05 on Windows03R2, the machine is a AD domain controller
(one and only in a test forest), SQL services run under an account with
Domain Admin and built-in\Administrators rights. All components (engine,
Integration services, etc) are installed to an E: volume and all services
run under the SQL-Services account I created. No errors anywhere, creating
a test db is fine.
Using the "Copy Database Wizard" fails at the "Create Package" step no
matter if "detach and attach" or "SQL mgnt object" method is used with the
same error (see below). Just a simple one table test db can not be copied
to the same server using the "copy db wizard" in SQL Server 2005.
It looks like the copy package can not be written to the MSDB. The create
package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I have
tried all kind of things - Giving the SQL-Services account db_owner rights
to MSDB (it should already have this from its sysadmin role and membership
in AD/Domain Admins built-in\admins). If there is something wrong with
using the "SQL Server Agent Service Account" as the Integration Services
Proxy account, I created security credentials and a Agent Proxy - but no
go - the wizard always fails at the create package step.
Please help, what am I missing?
=================================== No description found (Copy Database Wizard)
--
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()A little more investigation revealed that SS Business Intelligence DS will
not save a package to the server (it gets a similar error â' see below) and
the maintenance plan designer will not save a plan (it gets a "no description
found" error).
So there must be something seriously wrong with the SQL Server 2005
installation routine.
Maybe the installation failed (without error) because I at first installed
only some components to the E: drive and the rest of the components to the C:
drive. The installation screens are VERY poor in clearly describing what
will be installed where. So after I realized a bunch of components got
installed to C: and that the copy of Visual Studio that comes with SQL server
05 was installed to C: and that this would then FORCE the full version of VS
to C: I completely uninstalled SQL 2005.
I reinstalled all components to E: and then installed the full version of VS
(also to E:) â' all without error.
It is likely that the SQL Server 2005 installation routine is fragile â' and
it does not tell you about all errors it encounters. This is in complete
contrast to the SQL Server 2000 bullet proof installation routine.
I will do another complete uninstall of SQL 2005 and reinstall to see if
this helps.
Note, others have also reported this problem but not first with the copy db
wizard. Here is one:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=129472&SiteID=1
MikeC
Error from create SSIS package:
===================================
No description found (Microsoft Visual Studio)
--
Program Location:
at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package
package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword)
at
Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package)
at
Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)
"MikeC" wrote:
> Copying a db is an easy task under 2000, but 05...
> New install of SQL05 on Windows03R2, the machine is a AD domain controller
> (one and only in a test forest), SQL services run under an account with
> Domain Admin and built-in\Administrators rights. All components (engine,
> Integration services, etc) are installed to an E: volume and all services
> run under the SQL-Services account I created. No errors anywhere, creating
> a test db is fine.
> Using the "Copy Database Wizard" fails at the "Create Package" step no
> matter if "detach and attach" or "SQL mgnt object" method is used with the
> same error (see below). Just a simple one table test db can not be copied
> to the same server using the "copy db wizard" in SQL Server 2005.
> It looks like the copy package can not be written to the MSDB. The create
> package is step 3 of 5, step 1 (add log) and 2 (add task) work ok. I have
> tried all kind of things - Giving the SQL-Services account db_owner rights
> to MSDB (it should already have this from its sysadmin role and membership
> in AD/Domain Admins built-in\admins). If there is something wrong with
> using the "SQL Server Agent Service Account" as the Integration Services
> Proxy account, I created security credentials and a Agent Proxy - but no
> go - the wizard always fails at the create package step.
> Please help, what am I missing?
>
> ===================================> No description found (Copy Database Wizard)
> --
> Program Location:
> at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package
> package, IDTSEvents events, String packagePath, String serverName, String
> serverUserName, String serverPassword)
> at
> Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()
>
>|||I completely uninstalled SQL Server 2005 and all components - AGAIN.
This time, I deleted all remnants of SQL from the registry and file system -
SQL 2005 uninstall apparently is not as good as the SQL 2000 uninstall...
I reinstalled all components - and now saving packages works, including the
db copy wizard. Why? SQL 2005 install must have an intermittent bug or
somethingâ?¦
Now, have noticed a small bug with service status display, but it is minor.
When will we see SQL 2005 service pack one?
MikeC|||The failure to create a package on Win03R2/SQL05 is back!
This time, SSIS package saving worked fine for a while. I copied a few
development dbs over to 2005, then went away and did some other work on
SharePoint Services setup.
The server was rebooted and I ran the SQL setup - only to the point of
looking at what was installed - oddly the complete list of installed
components in setup is un-checked. I was looking for the SQL Server Mobile
components - they are not installed and I did not install them.
Anyway the problem is back. So it it not really an install problem. More
trouble-shooting is in order - the absolutely minimal error information
provided does not make it easy.
Have you seen this problem? Help!
MikeC|||It looks like reinstalling VS05pro after installing SQL05dev on Win03R2
CORRUPTS SQL Server 2005 Integration Services (a package cannot be saved to
server).
If I do the SQL05 install last, I avoid the problem. Now the question is -
what exactly gets corrupted and will this problem reappear when the VS SP1
comes out?
I think SQL Server 2000 was one of the best products that Microsoft created.
The SQL 2000 install was so simple and well behaved. Now, M$ has made SQL
Server into a monsters mess of DCOM linkages and registry bloat. Is it too
much to ask that M$ provide a simple install routine, one that displays a
manifest of files installed, and a list of registry changes? Maybe they are
ashamed of the mass of horrific registry db linkages put in to prop-up their
database â'programmingâ' model and want to pretend its not thereâ?¦
MikeC|||SQL05 creators - you must be joking - when you choose the Copy Database
""Wizard"" by right clicking on an existing db and then connect to another
server as a *source* you automatically select the local database as a copy
source **IN-ADDITION** to the db that a user needs to select on the remote
server.
In this case the remote db gets copied AND the local db gets copied - two
copies at the same time, so wacky! Just put in a copy db button to fix your
dangerous db copy interface.
MikeC

Copy Database Wizard Timeout Error

Hi,

I am copying a database from one server to the other. Both have SQL 2005. When using the CDW, I get the following error after 10 minutes:

Event Name: OnError

Message: An exception occurred while executing a Transact-SQL statement or batch.

StackTrace: at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteWithResults(String sqlCommand)

at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteWithResults(StringCollection sqlCommands)

at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()

InnerException-->Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

It always errors at 10 minutes. But, when I run the Create Database statement from my query analyzer, it works and it takes about 18 minutes.

How do I get the CDW to wait longer than 10 minutes before returning an error?

I have set my remote query timeout to 20 minutes and that didn't seem to have any effect.

Thanks,

--ExoStatic

Have you installed Service PAck 2? CDW is much improved.

Download SQL Server 2005 Service Pack 2 at:

http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/servicepacks/sp2.mspx

...probably doesn't matter but the job runs on the destination server so it timeouts are relevent they may need to be set on that server.

|||

We have greatly improved SMO transfer in CDW with Service Pack 2. I strongly suggest you try that. Also, you could try using the detach/attach method instead of SMO Transfer. I believe it is faster and more reliable.

After installing Service Pack 2, please let us know if your problem persists. You may still have to change some settings on your server.

Paul A. Mestemaker II
Program Manager
Microsoft SQL Server Manageability
http://blogs.msdn.com/sqlrem/

|||

if you use Detach/attach method you still need to migrate the Login from Source Server. You can also try Backup/Restore method which is best in such scenario. in this method also the Logins has to be taken care.

To transfer login Refer :http://support.microsoft.com/default.aspx/kb/246133

Madhu

sqlsql

Copy Database wizard issue

Despite the fact that both the package and the model db have the file locations set to e:\data\nnn, the SSIS package is creating / copying the files into C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data.

This is running as a job - could it be a security issue? I don't see any warning / error messages that would indicate an issue.Update...

This is sounding more and more like a bug.

I changed the model db file locations to the c:\ drive (diff location but known access).

no change

I changed the destination file location in the wizard-created SSIS package to the c:\ drive.

no change

No matter what I do, the wizard insists on putting the files into the program files directory listed above.

Both DB's live on the same physical server but different instances. I've combed through the log file and see no errors or warnings of any sort. The account the package is using (again according to the log) is an admin-level account.

I don't see anything on the feedback / bug site related to this.|||Given the deafening silence on this post, I've submitted a bug report. Feedback # is 236131|||

You were right to submit this as a defect. For others reading this thread, the link to the bug is: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=236131

We will investigate the issue and get back to you through the Connect site.

Regards,

Copy Database wizard issue

Despite the fact that both the package and the model db have the file locations set to e:\data\nnn, the SSIS package is creating / copying the files into C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data.

This is running as a job - could it be a security issue? I don't see any warning / error messages that would indicate an issue.Update...

This is sounding more and more like a bug.

I changed the model db file locations to the c:\ drive (diff location but known access).

no change

I changed the destination file location in the wizard-created SSIS package to the c:\ drive.

no change

No matter what I do, the wizard insists on putting the files into the program files directory listed above.

Both DB's live on the same physical server but different instances. I've combed through the log file and see no errors or warnings of any sort. The account the package is using (again according to the log) is an admin-level account.

I don't see anything on the feedback / bug site related to this.|||Given the deafening silence on this post, I've submitted a bug report. Feedback # is 236131|||

You were right to submit this as a defect. For others reading this thread, the link to the bug is: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=236131

We will investigate the issue and get back to you through the Connect site.

Regards,

Copy database wizard fails - copying 2000 dbs to new 2005 server

Hi, we recently upgraded our test database server to SQL 2005. We are trying
to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
the new test server. However, during the "Execution job" phase we receive
the following error message in the event log:
Event ID: 12550
Description:
Event Name: OnError
Message: Version80 database compatibility level is not supported.
any ideas on how I can resolve this issue? I have tried the export data
function and it works, however, we have stored procedures and DTS's set up on
these databases and would like a complete copy of the database on SQL 2005.
Any assistance is greatly appreciated.
Thanks!
Hi
"SoulCages" wrote:

> Hi, we recently upgraded our test database server to SQL 2005. We are trying
> to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
> the new test server. However, during the "Execution job" phase we receive
> the following error message in the event log:
> Event ID: 12550
> Description:
> Event Name: OnError
> Message: Version80 database compatibility level is not supported.
> any ideas on how I can resolve this issue? I have tried the export data
> function and it works, however, we have stored procedures and DTS's set up on
> these databases and would like a complete copy of the database on SQL 2005.
> Any assistance is greatly appreciated.
> Thanks!
I am not sure why you are not attaching the database files or restoring
backups?
John
|||John,
The two servers I am working with are on non-trusted domains and rather than
take all of our databases offline to copy them over to the server I was
hoping there was a way to do it while the databases are still online. (tried
using both methods in the copy database wizard but they fail with the message
below).
My goal is to bring the databases over exactly as they are today in SQL 2000
but migrate them to a 2005 testbed before we upgrade our existing SQL 2000
server to 2005 and set up replication.
I tried using the backup and attach methods but they do not allow you to
point to a network share. Both servers are in different buildings. What is
your recommended approach to handling this?
Thanks John,
Ryan Harris
"John Bell" wrote:

> Hi
> "SoulCages" wrote:
>
> I am not sure why you are not attaching the database files or restoring
> backups?
> John
|||Hi Ryan
"SoulCages" wrote:

> John,
> The two servers I am working with are on non-trusted domains and rather than
> take all of our databases offline to copy them over to the server I was
> hoping there was a way to do it while the databases are still online. (tried
> using both methods in the copy database wizard but they fail with the message
> below).
> My goal is to bring the databases over exactly as they are today in SQL 2000
> but migrate them to a 2005 testbed before we upgrade our existing SQL 2000
> server to 2005 and set up replication.
> I tried using the backup and attach methods but they do not allow you to
> point to a network share. Both servers are in different buildings. What is
> your recommended approach to handling this?
> Thanks John,
> Ryan Harris
>
You should be able to copy a backup file between the servers is probably
preferable to restoring from a UNC filename. You can then restore from the
copied file.
Database files can not be on a shared drive.
Have you run the SQL 2005 Upgrade Advisor on the current server?
HTH
John

Copy database wizard fails - copying 2000 dbs to new 2005 server

Hi, we recently upgraded our test database server to SQL 2005. We are trying
to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
the new test server. However, during the "Execution job" phase we receive
the following error message in the event log:
Event ID: 12550
Description:
Event Name: OnError
Message: Version80 database compatibility level is not supported.
any ideas on how I can resolve this issue? I have tried the export data
function and it works, however, we have stored procedures and DTS's set up on
these databases and would like a complete copy of the database on SQL 2005.
Any assistance is greatly appreciated.
Thanks!Hi
"SoulCages" wrote:
> Hi, we recently upgraded our test database server to SQL 2005. We are trying
> to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
> the new test server. However, during the "Execution job" phase we receive
> the following error message in the event log:
> Event ID: 12550
> Description:
> Event Name: OnError
> Message: Version80 database compatibility level is not supported.
> any ideas on how I can resolve this issue? I have tried the export data
> function and it works, however, we have stored procedures and DTS's set up on
> these databases and would like a complete copy of the database on SQL 2005.
> Any assistance is greatly appreciated.
> Thanks!
I am not sure why you are not attaching the database files or restoring
backups?
John|||John,
The two servers I am working with are on non-trusted domains and rather than
take all of our databases offline to copy them over to the server I was
hoping there was a way to do it while the databases are still online. (tried
using both methods in the copy database wizard but they fail with the message
below).
My goal is to bring the databases over exactly as they are today in SQL 2000
but migrate them to a 2005 testbed before we upgrade our existing SQL 2000
server to 2005 and set up replication.
I tried using the backup and attach methods but they do not allow you to
point to a network share. Both servers are in different buildings. What is
your recommended approach to handling this?
Thanks John,
Ryan Harris
"John Bell" wrote:
> Hi
> "SoulCages" wrote:
> > Hi, we recently upgraded our test database server to SQL 2005. We are trying
> > to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
> > the new test server. However, during the "Execution job" phase we receive
> > the following error message in the event log:
> >
> > Event ID: 12550
> >
> > Description:
> > Event Name: OnError
> > Message: Version80 database compatibility level is not supported.
> >
> > any ideas on how I can resolve this issue? I have tried the export data
> > function and it works, however, we have stored procedures and DTS's set up on
> > these databases and would like a complete copy of the database on SQL 2005.
> >
> > Any assistance is greatly appreciated.
> >
> > Thanks!
> I am not sure why you are not attaching the database files or restoring
> backups?
> John|||Hi Ryan
"SoulCages" wrote:
> John,
> The two servers I am working with are on non-trusted domains and rather than
> take all of our databases offline to copy them over to the server I was
> hoping there was a way to do it while the databases are still online. (tried
> using both methods in the copy database wizard but they fail with the message
> below).
> My goal is to bring the databases over exactly as they are today in SQL 2000
> but migrate them to a 2005 testbed before we upgrade our existing SQL 2000
> server to 2005 and set up replication.
> I tried using the backup and attach methods but they do not allow you to
> point to a network share. Both servers are in different buildings. What is
> your recommended approach to handling this?
> Thanks John,
> Ryan Harris
>
You should be able to copy a backup file between the servers is probably
preferable to restoring from a UNC filename. You can then restore from the
copied file.
Database files can not be on a shared drive.
Have you run the SQL 2005 Upgrade Advisor on the current server?
HTH
John

Copy database wizard fails - copying 2000 dbs to new 2005 server

Hi, we recently upgraded our test database server to SQL 2005. We are tryin
g
to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over to
the new test server. However, during the "Execution job" phase we receive
the following error message in the event log:
Event ID: 12550
Description:
Event Name: OnError
Message: Version80 database compatibility level is not supported.
any ideas on how I can resolve this issue? I have tried the export data
function and it works, however, we have stored procedures and DTS's set up o
n
these databases and would like a complete copy of the database on SQL 2005.
Any assistance is greatly appreciated.
Thanks!Hi
"SoulCages" wrote:

> Hi, we recently upgraded our test database server to SQL 2005. We are try
ing
> to use the "Copy Database Wizard" in 2005 to copy SQL 2000 databases over
to
> the new test server. However, during the "Execution job" phase we receive
> the following error message in the event log:
> Event ID: 12550
> Description:
> Event Name: OnError
> Message: Version80 database compatibility level is not supported.
> any ideas on how I can resolve this issue? I have tried the export data
> function and it works, however, we have stored procedures and DTS's set up
on
> these databases and would like a complete copy of the database on SQL 2005
.
> Any assistance is greatly appreciated.
> Thanks!
I am not sure why you are not attaching the database files or restoring
backups?
John