Hi all,

We are very interested in hearing from our users what are the top 10 issues
currently present in the SQL Server 2005 "Copy Database Wizard" that you
would like to see fixed/implemented (i.e. current problems and/or missing
functionality).

Thanks in advance for your feedback!

Cheers,
Oscar Naim
SQL Server
Program Manager

Perhaps you can help the person who placed the following post... :)

http://groups.google.com/group/microsoft.public.sqlserver.tools/browse_frm/thread/a1229fe2ce85fcf7/ed89f2463441d1a4?hl=en#ed89f2463441d1a4

Oscar Naim [MSFT] wrote:
Show quoteHide quote

The export/import wizard worked perfectly in 2000 for copying database
objects and data from one server to another.  In 2005 they have changed the
interface and broken it down to copy database and things don't seem to work
the same way, the wizard has lost functionality.  For example copying all the
dependant objects, or Appending data to exisiting data or overwriting it,
that type of functionality has been lost. 

Just a note,

Thanks,

Amadelle

Show quoteHide quote

Oscar,

I am glad you posted this question.

I have had several frustrations with the Copy Database Wizard. Here are
the problems I had when I was trying to transfer a small database from
SQL 2000 to 2005, without taking the source database offline:

1) Transfers fail if source DB is less than 3MB.

It reports that CREATE DATABASE failed with the error "Primary file
must be at least 3 MB to accommodate a copy of the model database."
However, there is no way to specify the size of the new database! (size
defaults to size of original, and is read-only).

2) Attempting a transfer without transferring logins always fails.

After changing the DB size of my target to 3MB, I tried again, and the
Event Log told me that "'Mig' is not a valid login or you do not have
permission." The error occurred on the query "EXEC dbo.sp_grantdbaccess
@loginame = N'Mig'".  In other words, I can choose not to transfer
logins, but it will still try to grant permissions to those
non-existent logins, and therefore fail.

3) Transferring with the logins fails the first time, then succeeds the
next.

Because of #2, I decided to go ahead and transfer the logins. I got the
exact same error regarding sp_grantdbaccess. I tried it a second time,
and it worked. Apparently, it executes the sp_grantdbaccess commands
before it transfers the logins, so it didn't work until the logins were
already there.

4) I can't pick and choose which database obects to transfer, as I
could in 2000.

Thanks for listening,

Argo

(argo.how***@gmail.com) writes:
What stupid thing!

I suggest that you file a bug for this on
https://connect.microsoft.com/SQLServer/Feedback.

While irritating it makes sort of sense. The logins may already be
present on the target server.

Hm, I think I've tried this, but had no problems. But I coped from SQL 2005
to SQL 2005. Given the many other bugs in CDW, I'm not surprised about
this one.

If you can reproduce the scenario, file bug for it on the URL I gave
above.

I think you should use the Import/Export options for this. After all,
it's called COPY DATABASE. And the default option is simply copy the
database files.

Erland Sommarskog wrote:
Erland, when you say "Import/Export options", are you referring to the
"Import and Export Wizard"? My problem with that is that it only
transfers data, not other objects.

In SQL 2000 EM, I could import and export any combination of objects,
and also avoid all these permission errors.

(argo.how***@gmail.com) writes:
OK, I have not looked into these very deeply.

Another option is Generate Scripts to get the objects. Here you can
select what to script.

Personally, I prefer to keep all code under source control and build
all databases from the version-control system, so I rarely have use for
scripting and the Copy Database Wizard myself.

Oscar - I have yet to get the Copy Database Wizard to work - at all.

Sql2005 runs as a less privileged user on all machines - and seems to require
admin priv levels to perform this task on both machines according to books on
line.

As I can, with the sam sa login create a database or drop it on either machine,
I do not see why this is the case.

I do not want SQL Server to run as a sysadmin - this is a security risk.

I always get this error msg:

While trying to find a folder on SQL an OLE DB error was encountered with error
code 0x80004005 (Login timeout expired).
(Copy Database Wizard)

Please fix this.

Also, as I'm right clicking on a database in the Management Console to attempt
to copy the database, rather annoying to have to enter this login info in again
for the source database in the copy wizard.

BTW - anyone have a good 3rd party solution that will perform this function?

Thanks, Les Caudle

On Wed, 7 Jun 2006 14:32:34 -0700, "Oscar Naim [MSFT]"
<on***@online.microsoft.com> wrote:

Show quoteHide quote

Transact Log truncate
Edit/Modify Stored Procedure in Management Console 2005
Using Query Analyzer with SQL 2005
database log truncated, transaction log backup job failed
! Distributing DMO For SQL 2000 !