It's not often a problem, but dropping objects in this manner can be inefficient ( I can recall waiting on numerous fet$ deletes) and could be difficult to recover from should it fail. Dropping a user "cascade" utilizes Oracle code and will be consistent AND complete from release to release. Writing a script such as this may not work when new object types or behaviors come into existence in Oracle 12, 13 etc. I also don't like the idea of passively leaving links or other objects assumed to be valid in a schema; why not just recreate needed objects properly, and exclude the rest. This avoids the chance that a new one was created in the source, but unwanted in the target. It's also more secure. I would certainly be in favor of first cloning an existing user as a new one, and then dropping the old, unless resources are unavailable to take such action. -- //www.freelists.org/webpage/oracle-l