Failed copy job deletes all users Since the progression of this was apparently somewhat difficult to follow the first time around:

I attempted a completely boring, been-done-a-thousand-times-before copy of a database using the copy database wizard with the detach/reattach method.

The copy failed.  The log indicates that it was unable to execute a CREATE VIEW action for a particular view, because the datasource for the view did not exist.  This is interesting in its own right, as the source most certainly exists, and the view(s) in question are fully functional in the source database.  I'm not really clear, just yet, on how significant this is, as I've yet to figure out precisely why this generated an error.  

This resulted in the deletion of all non-system user associations from the source database, leaving me with users dbo, information_schema, sys, and guest.  Non-system roles were also deleted.  Schemas were unaffected.  

I have since restored the damaged database from backup.  Academically, however, I would like to know the following:


Why would a failed copy operation strip the user associations from the source database?
Is there any sort of maintenance/rebuild/repair operation that could be performed on the source database to repair it?  
The loss of the users was immediately obvious, but given the rather mysterious nature of a failed copy job apparently damaging the source database, how concerned should I be about less obvious effects?  In theory, I would expect restoring from backup would alleviate this concern, but do I have any cause to worry about, e.g., the master database?


This is entirely repeatable.  I've made a handful of copies (manually) for the sake of experimenting with this particular issue, and in each case, the failed copy job obliterates the users and roles from the source database.  

Removing the views that generated errors allows the copy to complete, and, as one would expect, produces a copy with identical data, users, etc., in addition to leaving the source database unaltered.

If it's important, I've tried rebuilding the indexes of the system databases, as well as the damaged database, to no appreciable effect.  

The error generated:

1:00:25 PM,5/28/2013 1:00:25 PM,0,0x,ERROR : errorCode=-1073548784 description=Executing the query "CREATE VIEW [Sourcing].[PermittedArrProducts]
AS
SELECT     dbo.tblArrProducts.ArrProductID, dbo.tblArrProducts.ArrangementID, dbo.tblArrProducts.ContainerTypeID, dbo.tblArrProducts.Quantity
FROM         Sourcing.PermittedArrangements INNER JOIN
                      dbo.tblArrProducts ON Sourcing.PermittedArrangements.ArrangementID = dbo.tblArrProducts.ArrangementID

" failed with the following error: "Invalid object name 'Sourcing.PermittedArrangements'.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
So, after Mark's question above, I did some more searching around with much more generic terms (essentially ignoring the loss of the users and just focusing on the fact that the copy job was failing), and came across this thread, this thread, and this thread all of which seem to pretty closely match what I'm experiencing.  This lead me to the observation that, while the views functioned in use, their dependencies were no longer marked, which was what caused the copy job to fail. 

While I'm still a bit curious as to why a failed copy job would wipe out the users in the source database (and why it seems "stuck" in SMO mode), I think this should more or less answer my question.  Thanks everyone.