¿Hay alguna forma de forzar la Resolución de nombre diferido incluso si la tabla existe al crear un procedimiento almacenado?

Al crear un procedimiento almacenado en SQL Server, puede hacer referencia a tablas que no existen. Pero, si la tabla existe, entonces cualquier columna a la que se refiera en el procedimiento debe existir en esa tabla ( Resolución de nombre diferido ).

¿Es posible indicar a SQL Server que difiera la resolución de nombres de todas las tablas a las que se hace referencia en un procedimiento, independientemente de si existen o no? Quiero mantener la comprobación general de la sintaxis, por lo que, incluso si fuera posible, piratear la definición del procedimiento almacenado en una tabla del sistema no es una opción.

Supongo que pedir esto puede parecer un poco extraño , así que aquí hay algunos antecedentes: genero automáticamente definiciones de tabla y procedimientos almacenados a partir de una aplicación escrita en C # y es muy difícil para mí cambiar el código para ordenar los cambios según lo necesite SQL ellos. Mi código "garantiza" que el esquema es coherente dentro de una transacción, pero actualmente no puedo garantizar que las columnas de la tabla estén definidas antes de definir el procedimiento almacenado que hace referencia a ellas.

A continuación se muestra un ejemplo canónico del SQL creado por C # que "ilustra" el problema que estoy tratando de resolver.

--Say this table already exists.
CREATE TABLE myTable
(
    a NVARCHAR(MAX)
)
GO

--My C# code creates something like this
BEGIN TRAN 
GO

--the stored procedure gets generated first.
CREATE PROCEDURE mySproc
AS
BEGIN
    SELECT a,b FROM myTable
END

--then the table update
ALTER TABLE myTable
    ADD b nvarchar(MAX)

COMMIT TRAN 

Que es posible para mí Para solucionar esto en el código C #, pero estoy esperando por una simple "mágica" ajustar puedo tirar en el SQL. Esto me ahorrará mucho tiempo.

No.

Me siento realmente culpable simplemente escribiendo eso, pero no, tristemente. Es la primera vez que escucho sobre este caso de uso, y tiene mucho sentido. Lo mejor es enviar una solicitud en http://connect.microsoft.com y sus nietos podrán hacerlo. ;-)

En caso de que todavía esté interesado, existe una posible solución alternativa que puede emplear. Aquí está el código actualizado, que introduce la #deferResolutiontabla temporal para cada consulta en el procedimiento. Debido a que la tabla temporal solo existirá en tiempo de ejecución, el procedimiento puede compilarse aunque las columnas adecuadas aún no existan myTable.

Incluso obtendrá el mismo plan de ejecución (sin referencia a la #deferResolutiontabla) para cada instrucción en el procedimiento debido a la forma en que el optimizador de consultas puede probar que esto WHERE NOT EXISTSsiempre se evalúa como verdadero.

Dicho todo esto, este es un truco terrible presentado principalmente por interés intelectual y podría haber un caso extremo en el que se rompe. Como Aaron menciona, probablemente sería mejor hacer todos los cambios de esquema en el orden correcto.

--Say this table already exists.
CREATE TABLE myTable
(
    a NVARCHAR(MAX)
)
GO

--My C# code creates something like this
BEGIN TRAN 
GO

--the sproc gets generated first.
CREATE PROCEDURE mySproc
AS
BEGIN
    CREATE TABLE #deferResolution (dummy INT NOT NULL)
    SELECT a,b FROM myTable WHERE NOT EXISTS (SELECT * FROM #deferResolution WHERE 0=1)
END

--then the table update
ALTER TABLE myTable
    ADD b nvarchar(MAX)

COMMIT TRAN