Your dependencies will probably be completely out of whack, but I haven't thoroughly tested this. I do know that in this scenario:
CREATE SCHEMA blat AUTHORIZATION dbo;
GO
CREATE TABLE dbo.foo(a INT PRIMARY KEY);
CREATE TABLE dbo.bar(a INT FOREIGN KEY REFERENCES dbo.foo(a));
GO
CREATE PROCEDURE dbo.pX AS
BEGIN
SET NOCOUNT ON;
SELECT a FROM dbo.bar;
END
GO
CREATE VIEW dbo.vFooBar
AS
SELECT foo.a, bar.a AS barA
FROM dbo.foo
INNER JOIN dbo.bar
ON foo.a = bar.a;
GO
ALTER SCHEMA blat TRANSFER dbo.foo;
ALTER SCHEMA blat TRANSFER dbo.bar;
ALTER SCHEMA blat TRANSFER dbo.pX;
ALTER SCHEMA blat TRANSFER dbo.vFooBar;
The foreign keys actually migrate more smoothly than I expected (with the caveat that I'm testing on a much more recent version than you). But because the code in blat.pX
still references dbo.bar
, obviously executing the procedure:
EXEC blat.pX;
Is going to yield this error:
Msg 208, Level 16, State 1, Procedure pX
Invalid object name 'dbo.bar'.
And dependency queries, such as:
SELECT * FROM sys.dm_sql_referenced_entities('blat.pX', N'OBJECT');
Will yield this error:
Msg 2020, Level 16, State 1
The dependencies reported for entity "blat.pX" might not include references to all columns. This is either because the entity references an object that does not exist or because of an error in one or more statements in the entity. Before rerunning the query, ensure that there are no errors in the entity and that all objects referenced by the entity exist.
And querying the view:
SELECT a, barA FROM blat.vFooBar;
Yields these errors:
Msg 208, Level 16, State 1, Procedure vFooBar
Invalid object name 'dbo.foo'.
Msg 4413, Level 16, State 1
Could not use view or function 'blat.vFoobar' because of binding errors.
So, this could involve a lot of cleanup. And after you've fixed all the object references, you'll probably want to recompile all of the modules and refresh all of the views in the new schema. You can generate a script for that quite similar to the example above.
Best Answer
Yes, this can be done.
In the open source community, it has been done for years. In most situations, they just prefixed the tables.
I am not aware of a tool to simplify the process.
You are aware that you introduce new challenges.
An alternative approach is to move to multi-tenant design. Add a new field to all tables. Let's call it ClientId. Add filtered indexes. Now all queries need to be filtered on ClientId. You still need to deal with any auto increment columns.