I used the Copy SQL-Server Objects Task to copy tables and views from a
production server to a reporting server. On the production database I created
a database user i.e. ReadUser. On the Reporting database I created the
database user WriteUser. In the Task I defined the ReadUser for the Source
database connection and the WriteUser for the Destination database. I choose
to copy all tables and views and made sure that no privileges or triggers or
whatever would be copied along with the objects (Options in Copy tab).

The funny thing I see is that all tables get the owner dbo, but all views,
exept 2, get the owner WriteUser. I do this with one task. I can't find any
reasson why this is happening. I hop e anyone can tell me why this is
happening.

I dislike this task for his very reason, i.e. it is difficult to use. I
always script things out and apply (Procs, Views etc) and transfer the data
using DataPump tasks.


"freterink" <freterink (AT) discussions (DOT) microsoft.com> wrote

I have to transfer over a hundred of objects (tables and views). Using data
pump tasks means I have to make a task for every object (as far as I know).
That's why I use this Task.

Is the behaviour of this task meant like this or is it faulty?

"Allan Mitchell" wrote:

For tables then you can use the wizard to do the DataPump
generation

To do the views I would script them out and apply.

The copy of tables has to be done every morning at 04:00. I copy entire
tables to make sure that I receive date including new definitions. Your
solutions seems to me a manual task.

In the meantime I have created a Stored Procedure that changes the owner of
the views to dbo.

"Allan Mitchell" wrote:

Personally if I was transferring the whole lot I would use BACKUP and
RESTORE. I would then run any post RESTORE scripts to change any details

--

Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.konesans.com


"freterink" <freterink (AT) discussions (DOT) microsoft.com> wrote