permisos - procedimientos almacenados en sql server 2014
¿Por qué SQL Server no puede modificar una vista en un procedimiento almacenado? (1)
Creo que las respuestas son:
- MS quiere evitar que DDL se ejecute desde procedimientos.
- El código dentro de la declaración ejecutiva no se trata como parte del procedimiento, por lo que no está sujeto a las mismas restricciones que el procedimiento.
- No.
Un enfoque alternativo podría ser tener una tabla separada (llamada algo así como swing_table) con 1 o 0 registros para indicar si la vista debe consultar la tabla de producción u otra (¿copia de seguridad?) Respectivamente, algo así como:
create view viewname as
select {field list}
from production_table
cross join swing_table
union all
select {field list}
from backup_table
where (select count(*) from swing_table) = 0
- luego TRUNCATE swing_table dentro del procedimiento cuando quieras, erm, balancear la tabla, ya que TRUNCATE no es un comando transaccional, debería ejecutarse inmediatamente.
Estoy usando MS SQL Server, y me gustaría modificar una vista desde dentro de un procedimiento almacenado, ejecutando algo así como "alterar vista VIEWNAME como ([some sql])".
Algunas páginas arrojadas por google afirman que esto no se admite directamente (y tampoco lo son las declaraciones relacionadas de alter-table), pero también hay ejemplos de cómo solucionarlo utilizando construcciones como esta:
declare @sql varchar(max)
select @sql = ''alter view VIEWNAME as ([some sql])''
exec(@sql)
Escribir código como cadenas literales huele un poco, incluso para SQL.
Mis preguntas:
- ¿Por qué esto no es compatible? ¿Cuál es la diferencia entre ejecutar esto desde un sproc y ejecutarlo como una declaración independiente?
- ¿Por qué funciona la solución mediante la
exec
de la cadena de SQL literal? Mi comprensión de la declaraciónexec
es que simplemente ejecuta el SQL en línea, ¿es incorrecto? - (No es optimista) ¿Hay alguna forma mejor de realizar un cambio en una vista desde un procedimiento almacenado?