Problema columna computada persisted

miércoles, 19 de mayo de 2010
Publicado por Ivan 0 comentarios

En "el extraño caso" de hoy, està el de la columna computada persisted en SQL Server 2005. Cuenta la leyenda que luego de crear una columna computada persisted en SQL Server 2005, un informático se tuvo que enfrentar a problemas relativos a que no se pudieron realizar operaciones de update o insert sobre la tabla que tenìa asociada la columna computada, supuestamente porque los ANSI estaban mal definidos (ANSI_NULL, QUOTED_IDENTIFIER, ARITHABORT, entre otros).


Esto se debe a que las columnas computadas declaradas persisted permiten la indexación, al contrario de las no persisted, y como para indexar columnas computadas o vistas es necesario que los ANSI estèn ON, y estaban por defecto en la base de datos en OFF, entonces eso era lo que estaba provocando el problema.

Solución?. En realidad hay varias dependiendo de las condiciones. En mi caso particular decidí no hacerla persisted, por lo que entonces los ANSI ya no son exigidos, y todo funcionaría de maravillas. Y así fué, no hubieron mas errores en updates o inserts sobre la tabla.

Aprovecho de acotar que en realidad las columnas computadas son soportadas desde SQL Server 2000, pero en ese entonces no se soportaba la propiedad persisted, que fuè habilitada en SQL Server 2005 junto con la indexacion de vistas. A lo mejor por ahi va la cosa.

Renombrar columnas o tablas en SQL Server

lunes, 3 de mayo de 2010
Publicado por Ivan 0 comentarios

Ese era el problema!, como cambio el nombre de una columna o tabla en SQL Server??. Tenía una columna computada relacionada a otras dos columna, y todas debían desaparecer en beneficio de una columna que se llamaría igual que la columna computada. Para eso, cree una columna con un nombre distinto, actualice su valor en base al de la columna computada, y luego eliminé esas 3 columnas que no necesitaba. Y ahora, venía la parte en que debía renombrar la columna.

Para esto, existe un procedimiento almacenado llamado sp_rename, cuyo uso para renombrar una columna es:

sp_rename 'nombre_Tabla.nombre_columna', 'nuevo_nombre_columna', 'COLUMN'

El 'COLUMN' es invariable, siempre va. Y para cambiar el nombre a una tabla, más sencillo aún:
sp_rename 'nombre_antiguo_tabla', 'nombre_nuevo_tabla'.

Y esto gracias a otro personaje que me dió el dato, y que está aquí

Procedimiento almacenado de SQL Server demora mucho.

Publicado por Ivan 2 comentarios

Nuevamente el titulo es bastante genérico, por lo que paso a detallar el problema.

El problema era el siguiente: Uso powerbuilder para desarrollar, y en esta herramienta hay un objeto que es la piedrangular de powerbuilder, que es la datawindow. Es una datagrid pero con esteroides, buenos métodos y estados. En ella se especifica una consulta sql, y con eso retorna los valores en si misma, que pueden ser modificados, ingresados nuevos valores o eliminados, y luego se llama al método update de la misma, y solita construye los insert, delete o updates necesarios para que todo quede como lo dejamos en la datawindow.

En fin!, generalmente cuando debo hacer informes en ella genero la consulta en el administrador de sql server para asegurarme que me traiga los resultados que necesito, y luego la copio en la datawindow. Esta consulta tenìa un parámetro, por lo que en el administrador usaba una variable para simular el funcionamiento que tendría en la datawindow, y bien!!!, demoraba 6 segundos en traer lo que que necesitaba. Copié en la datawindow, lo probé, y..... rayos!!!, demoraba 11 minutos!!!!.

Pensé que a lo mejor la datawindow podría estar mal, la hice de nuevo, le copie la consulta, y lo mismo. No me explicaba como la misma consulta demoraba tanto ejecutada desde la datawindow, y tan poco desde el administrador de SQL Server. Luego, pensé que llamando los resultados desde un procedimiento almacenado podría apurar un poco las cosas, y mi sorpresa fué mayor cuando luego de crear el procedimiento lo ejecuté en el mimo administrador de sql y rayos!!!, 11 minutos tambien!!!!.

Luego de pegarme un par de cabezasos decidí preguntar a mis colegas para ver si a alguno le habia pasado lo mismo, y llegué al jefe. Ahí me comentó que tampoco sabía porqué, pero que eso se arreglaba tomando el parametro pasado al procedimiento, asignandolo a una variable dentro del procedimiento, y luego usando dicha variable en vez del argumento del procedimiento.

Extrañó!, debería ser lo mismo, pero probé y chan!!!!, pasamos de 11 minutos a 6 segundos. El jefe suponía que seguramente los argumentos de los procedimientos almacenados son almacenados en un área no optimizada o muy concurrida, tal que a lo mejor por eso hay demoras excesivas para acceder al valor de dicho argumento cuando el procedimiento almacenado lo necesita.

En resumen, la solución pasa por tomar las variables del argumento del procedimiento, y ponerlas en variables locales al procedimiento, y luego ejecutar el procedimiento almacenado. Con esto, asunto arreglado!!!!!