SQL Server

El uso de procedimientos almacenados es una de las bases del desarrollo robusto en SQL Server. Aportan encapsulamiento, seguridad, rendimiento y reutilización del código. Pero como cualquier otro elemento persistente de base de datos, su eficacia no reside solo en lo que hacen, sino en cómo están definidos y estructurados. En este artículo repasaremos una serie de buenas prácticas que deberíamos aplicar de forma sistemática al crear procedimientos almacenados, tanto desde el punto de vista funcional como desde una perspectiva de mantenimiento y rendimiento.

Estructura básica de los procedimientos almacenados

Todo procedimiento almacenado debería comenzar por una cabecera clara, que incluya las opciones de sesión imprescindibles. Estas opciones afectan al comportamiento del objeto y quedan almacenadas junto con su definición, por lo que no deben dejarse al azar:

SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;
GO

CREATE PROCEDURE dbo.ObtenerClientesActivos
    @Pais NVARCHAR(100)
AS
BEGIN
    SET NOCOUNT ON;

    SELECT *
    FROM dbo.Clientes
    WHERE Pais = @Pais AND Activo = 1;
END;
GO

Las opciones ANSI_NULLS y QUOTED_IDENTIFIER son obligatorias para garantizar compatibilidad con vistas indexadas, funciones deterministas y otras funcionalidades. Y SET NOCOUNT ON evita el envío innecesario de mensajes como “(x filas afectadas)”, lo cual mejora el rendimiento en operaciones masivas o dentro de cursores.

Nombres coherentes y significativos para procedimientos almacenados

Otro de los mejores consejos que podemos seguir a la hora de crear procedimientos almacenados es que los nombres deben seguir una convención clara y consistente. Lo ideal es utilizar un prefijo común, como el esquema dbo o app, y un verbo que indique claramente la acción. Evitemos prefijos de sistema como sp_, ya que están reservados para procedimientos del sistema. Cuando un procedimiento almacenado empieza por sp_ SQL Server realiza una búsqueda prioritaria en la base de datos master, lo que afecta al rendimiento y puede provocar colisiones de nombres. Si quieres que el prefijo especifique claramente que es un procedimiento almacenado yo soy más partidario de prefijos como usp_ (User Stored Procedure) pero, esto ya va en gustos. Te dejo unos ejemplos de lo que para mi serían buenos nombres:

• dbo.usp_ObtenerClientesPorCiudad
• app.usp_ActualizarStockProducto
• dbo.usp_InsertarPedidoCabecera

Declara los parámetros de los procedimientos almacenados de forma explícita y validada

Todo parámetro debe tener un tipo de dato bien definido, preferiblemente sin utilizar tipos innecesariamente amplios como NVARCHAR(MAX) o INT si con TINYINT es suficiente. Además, es una buena práctica validar parámetros críticos antes de ejecutar lógica compleja:

IF @Pais IS NULL
BEGIN
    RAISERROR('El parámetro @Pais no puede ser NULL.', 16, 1);
    RETURN;
END

Esto permite fallos controlados y evita errores más adelante que sean difíciles de rastrear. Si no quieres usar RAISERROR también puedes dejar log en una tabla diseñada para este fin.

Evita la lógica excesiva en un solo procedimiento almacenado

Un error común es concentrar demasiada lógica en un solo procedimiento, lo que dificulta su mantenimiento, pruebas unitarias y reutilización. Si un procedimiento está realizando múltiples tareas (validación, inserción, actualización, notificación…), es mejor dividirlo en partes más pequeñas y orquestarlas desde uno principal.

Además, si reutilizamos lógica compartida entre procedimientos, podemos encapsularla en funciones o en procedimientos secundarios.

Utiliza transacciones de forma segura y explícita en tus procedimientos almacenados

Si un procedimiento realiza más de una operación que debe completarse como una unidad, debemos protegerla con una transacción. Pero cuidado, de nada sirve iniciar una transacción si no vamos a contar con que puede haber errores y tenemos planificado rollback cuando sea necesario.

BEGIN TRY
    BEGIN TRANSACTION;

    – Operaciones críticas
    UPDATE Stock SET Cantidad = Cantidad - @Cantidad WHERE ProductoID = @ProductoID;
    INSERT INTO LogTransacciones (...)

    COMMIT;
END TRY
BEGIN CATCH
    IF XACT_STATE() <> 0
        ROLLBACK;

    RAISERROR('Error en la operación: %s', 16, 1, ERROR_MESSAGE());
END CATCH;

Esto garantiza integridad de datos y un control efectivo de los errores. Nuevamente, también puedes usar una tabla de log en vez de RAISERROR.

Documenta todos tus procedimientos almacenados

Seamos claros, para mi este punto no es opcional. Una breve cabecera que explique qué hace el procedimiento, qué parámetros recibe y qué devuelve es una inversión de tiempo que ahorra horas de análisis futuro. Especialmente en equipos grandes o proyectos duraderos, esta práctica marca una gran diferencia.

/*
Nombre: dbo.ObtenerClientesPorPais
Descripción: Devuelve todos los clientes activos de un país concreto.
Parámetros:
  @Pais (nvarchar) – Nombre del país
Autor: Roberto Carrancio - www.soydba.es
Fecha: 2025-03-31
*/

Cuidado con el uso de SELECT * en procedimientos almacenados

El uso de SELECT * dentro de código que se va a persistir puede ser cómodo al principio, pero es una mala práctica y te dará problemas en cuanto el esquema cambie. Rompe la estabilidad del contrato de salida del procedimiento y complica la integración con aplicaciones externas. En su lugar, deberíamos listar explícitamente las columnas:

SELECT ClienteID, Nombre, Email
FROM dbo.Clientes
WHERE Activo = 1;

Añade a tus procedimientos almacenados un control de errores robusto

Todo procedimiento que modifique datos debe incluir manejo de errores. Además del bloque TRY…CATCH, conviene capturar el código y mensaje del error para diagnóstico:

BEGIN CATCH
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    DECLARE @ErrorNumber INT = ERROR_NUMBER();
    DECLARE @ErrorSeverity INT = ERROR_SEVERITY();

    RAISERROR('Error %d: %s', @ErrorSeverity, 1, @ErrorNumber, @ErrorMessage);
    RETURN;
END CATCH;

También puede ser útil registrar errores en una tabla de log para su análisis posterior.

Cuida el rendimiento de los procedimientos almacenados desde el diseño

Cuantas veces hemos oido eso de “Es que en desarrollo funcionaba…”. Cada vez que definimos un procedimiento, estamos estableciendo un plan de ejecución potencialmente reutilizable. Además, como son objetos que se van a persistir tenemos que tener en cuenta que los datos van a crecer en algún momento y el rendimiento tiene que seguir siendo óptimo. Aunque con datos de desarrollo o en etapas tempranas del proyecto pueda parecer que no hace falta invertir tiempo en la optimización te prometo que tu yo del futuro te agradecerá que lo hayas pensado a tiempo. Algunas recomendaciones básicas podrían ser:

• No uses OPTION (RECOMPILE) si no es estrictamente necesario (casi nunca lo es).
• Declara los parámetros con tipos de datos que coincidan con las columnas.
• Evita subconsultas complejas innecesarias.
• Usa EXISTS en lugar de COUNT(*) si solo interesa saber si hay filas.
• Indexa correctamente las tablas que usas como origen o destino.

Pruebas, idempotencia y versionado de los procedimientos almacenados

En general, es buena práctica que los procedimientos sean idempotentes si su función lo permite (es decir, que al ejecutarse más de una vez no cambien el resultado final).

Además, es recomendable mantener versiones numeradas y fechadas en sistemas donde los procedimientos evolucionan con el tiempo, y anotar los cambios relevantes en el propio código fuente.

Conclusión

Definir procedimientos almacenados no es solo cuestión de escribir lógica T-SQL funcional. Es una disciplina que requiere previsión, consistencia y enfoque estructurado. Aplicando estas buenas prácticas, conseguimos objetos más fiables, mantenibles y adaptables a largo plazo.

Tengo en mi lista de posibles futuros artículos aspectos complementarios a este artículo como procedimientos para auditoría, patrones para operaciones masivas o generación dinámica de SQL con seguridad. Mientras tanto, si aún no lo has hecho, te invito a revisar nuestro artículo sobre opciones SET imprescindibles al crear procedimientos, un complemento perfecto para consolidar estos conceptos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

En nuestro día a día trabajando con SQL Server, a menudo escribimos consultas y procedimientos almacenados sin detenernos a pensar en el contexto de ejecución que los rodea. Sin embargo, en segundo plano, hay una serie de configuraciones que condicionan profundamente cómo se interpretan, ejecutan y optimizan nuestras instrucciones T-SQL. Me refiero a las opciones que se establecen con la instrucción SET, y que van mucho más allá de unas simples “banderas”.

En este artículo repasamos las opciones SET más relevantes, agrupándolas por su impacto funcional y destacando aquellas que no deberían faltar en ningún entorno profesional. No todas las opciones son igual de conocidas, pero su uso adecuado marca la diferencia entre un código fiable y uno plagado de inconsistencias.

¿Qué hace realmente SET en T-SQL?

La instrucción SET en T-SQL permite establecer opciones de sesión que afectan al comportamiento del motor en aspectos como comparación de valores nulos, comportamiento de las transacciones, uso de cursores, sintaxis permitida o restringida, interpretación de identificadores o precisión y formato de resultados

Estas opciones afectan a la sesión actual y, en algunos casos, se heredan en la creación de objetos como procedimientos, vistas o funciones. Por ello, es fundamental entender qué estamos configurando, especialmente en entornos donde se combinan herramientas de desarrollo, procesos automatizados y ejecución mediante SQL Server Agent.

Opciones SET más críticas para el desarrollo y despliegue

Algunas opciones son especialmente relevantes porque afectan de forma directa a la definición y comportamiento de objetos persistentes. Estas deben estar activadas siempre antes de crear procedimientos almacenados, índices filtrados, vistas indexadas o columnas calculadas indexadas.

ANSI_NULLS

Ya lo analizamos en profundidad en este artículo sobre ANSI_NULLS, pero recordamos que debe estar activado para permitir comparaciones nulas según el estándar ANSI. Obligatorio para vistas indexadas, columnas calculadas e índices filtrados.

QUOTED_IDENTIFIER

Controla si las comillas dobles se interpretan como delimitadores de identificadores. Debe estar activado para usar funcionalidades modernas como índices XML, MERGE, vistas indexadas y más. Lo explicamos en detalle en este artículo dedicado.

ANSI_PADDING

Afecta a cómo se almacenan los valores en columnas CHAR y VARCHAR, así como BINARY y VARBINARY. Su valor queda grabado en la definición de columnas y también es imprescindible al crear índices en columnas de longitud fija.

Opciones SET que afectan a la lógica de ejecución

Algunas opciones SET influyen directamente en cómo se evalúan las instrucciones T-SQL, en especial las condiciones, errores y tipos de datos.

ARITHABORT

Si está activado, provoca que una consulta se detenga ante errores de desbordamiento aritmético (como división por cero). Es obligatorio tenerlo activado para usar vistas indexadas y estadísticas precisas durante la optimización de consultas.

CONCAT_NULL_YIELDS_NULL

Controla si concatenar NULL con una cadena devuelve NULL o no. Es recomendable mantenerlo activado para seguir el comportamiento ANSI:

NUMERIC_ROUNDABORT

Si está activado, cualquier redondeo de datos DECIMAL o NUMERIC provocará un error. Por defecto está desactivado, y debe permanecer así si queremos trabajar con vistas indexadas o funciones deterministas.

Opciones SET que afectan a transacciones y control de errores

Vamos a ver ahora esas opciones SET que definen cómo se van a comportar nuestras transacciones, en especial ante errores.

XACT_ABORT

Al activarlo, cualquier error en una transacción hace que se aborte automáticamente, lo que evita estados intermedios o inconsistentes. Es especialmente útil cuando se trabaja con transacciones distribuidas o procedimientos de mantenimiento.

IMPLICIT_TRANSACTIONS

Al activarse, cada instrucción que modifica datos inicia una transacción automáticamente, que debe cerrarse de forma explícita. Aumenta el control, pero puede provocar bloqueos si se olvida un COMMIT o ROLLBACK.

Opciones SET que afectan a cursores y resultados

Otro de los grupos de opciones SET son las que afectan a cursores y a los resultados de las consultas.

CURSOR_CLOSE_ON_COMMIT

Determina si los cursores abiertos se cierran automáticamente al hacer COMMIT. Por defecto está desactivado, permitiendo que el cursor siga abierto. En general, es buena práctica mantener el control explícito de los cursores pero implica llevar cierto cuidado y acordarnos de cerrarlos cuando terminemos de trabajar con ellos.

ANSI_WARNINGS

Activa advertencias para operaciones con datos truncados, errores de tipo de datos, división por cero, etc. Debe estar activado para crear vistas indexadas y columnas calculadas.

Opciones SET de formato

Por último, vamos a ver el grupo de opciones SET que nos permiten configurar los formatos y comportamientos de los datos.

DATEFIRST, LANGUAGE, DATEFORMAT

Estas opciones controlan la interpretación de fechas y días de la semana, especialmente en funciones como DATENAME, DATEPART o expresiones con formatos ambiguos. Son críticas en sistemas multi-región o migraciones.

SET DATEFIRST 1;        -- Semana empieza en lunes
SET LANGUAGE 'Spanish'; -- Nombres en español
SET DATEFORMAT dmy;     -- Día / Mes / Año

TEXTSIZE

Controla el tamaño máximo (en bytes) de datos TEXT, NTEXT o IMAGE devueltos por una consulta. En algunos entornos, limitarlo evita retornos innecesarios de grandes volúmenes de datos binarios.

Buenas prácticas: estandarización en scripts y entornos

Para evitar inconsistencias entre entornos, sesiones o herramientas, es recomendable fijar siempre las opciones clave de forma explícita en la cabecera de scripts de despliegue, procedimientos y vistas. Un bloque típico sería este:

SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET ARITHABORT ON;
SET CONCAT_NULL_YIELDS_NULL ON;
SET NUMERIC_ROUNDABORT OFF;

Además, en los jobs de SQL Server Agent o entornos que generan T-SQL de forma dinámica, estas configuraciones deben añadirse manualmente, ya que el valor por defecto suele ser distinto al del entorno interactivo de SSMS.

Conclusión

Las opciones SET en T-SQL no son meros ajustes cosméticos, son configuraciones que determinan cómo se comporta SQL Server en aspectos fundamentales como la lógica booleana, el almacenamiento físico de los datos, el control de errores y la compatibilidad ANSI. Conocerlas y aplicarlas correctamente es una responsabilidad crítica para cualquier desarrollador o DBA. Establecerlas de forma explícita no solo previene errores, sino que garantiza que nuestros objetos sean coherentes, portables y preparados para integrarse con las capacidades más avanzadas del motor de base de datos.

¿Quieres profundizar más en el impacto de estas opciones en vistas indexadas o columnas calculadas? Te recomendamos leer nuestros artículos sobre QUOTED_IDENTIFIER y ANSI_NULLS y ANSI_PADDING, donde exploramos con más detalle cómo afectan a la creación y uso de objetos persistentes en SQL Server.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

En el ecosistema de SQL Server, ciertas opciones de sesión pueden parecer simples banderas de configuración sin mayor trascendencia. Sin embargo, cuando hablamos de ANSI_NULLS y ANSI_PADDING, nos referimos a directivas que afectan de forma directa y permanente a la definición de objetos como procedimientos, índices, vistas o tablas. Ignorar su correcto uso puede derivar en errores sutiles, comportamientos inesperados y problemas de compatibilidad en entornos modernos. En este artículo profundizaremos en su función, implicaciones y mejores prácticas.

Introducción: más que opciones de sesión

Tanto ANSI_NULLS como ANSI_PADDING son opciones heredadas del estándar ANSI SQL y forman parte de las configuraciones que influyen en cómo SQL Server interpreta y almacena los datos. Lo relevante es que, al igual que QUOTED_IDENTIFIER, estas opciones no solo afectan a la sesión actual, sino que quedan asociadas al objeto creado o modificado en ese contexto.

Esto significa que si definimos una tabla, índice o procedimiento con una de estas opciones desactivadas, su comportamiento futuro dependerá de ese estado, aunque cambiemos la configuración más adelante. Veamos en detalle cómo afecta cada una.

ANSI_NULLS: el comportamiento de las comparaciones con NULL

Cuando ANSI_NULLS está activado, se sigue el estándar ANSI para el tratamiento de valores nulos. Esto implica que cualquier comparación de una columna con valor NULL mediante el operador = o <> devolverá FALSE, ya que los NULL no se consideran iguales ni distintos a ningún otro valor, incluido otro NULL.

Ejemplo con ANSI_NULLS ON:

SET ANSI_NULLS ON;
SELECT * FROM Empleados WHERE Departamento IS NULL; -- correcto
SELECT * FROM Empleados WHERE Departamento = NULL;  -- no devuelve resultados

En cambio, si desactivamos ANSI_NULLS, SQL Server permite que Departamento = NULL devuelva resultados, rompiendo la lógica ANSI y provocando código no portable y difícil de mantener.

Requisitos del motor

SQL Server exige que ANSI_NULLS esté activado para crear:

• Vistas indexadas
• Índices en columnas calculadas.
• Índices en columnas filtradas
• Funciones con determinismo
• Replicación, CDC, tablas temporales o cualquier funcionalidad avanzada

Además, al igual que con QUOTED_IDENTIFIER, el estado de ANSI_NULLS se graba con los objetos persistentes como procedimientos almacenados. Y una vez definidos, no se puede cambiar este comportamiento salvo recreando el objeto.

ANSI_PADDING: control del almacenamiento de datos tipo CHAR y BINARY

Mientras que ANSI_NULLS afecta a la lógica de comparación, ANSI_PADDING determina cómo se almacenan los valores que se insertan en columnas CHAR, VARCHAR, BINARY o VARBINARY, especialmente cuando se trata de cadenas más cortas que la longitud definida en la columna.

Cuando ANSI_PADDING está activado los valores de tipo CHAR y BINARY se rellenan con espacios o ceros hasta la longitud declarada. Además los valores de tipo VARCHAR y VARBINARY se almacenan tal cual, sin relleno y los valores NULL se almacenan correctamente.

En cambio, cuando está desactivado, los valores de VARCHAR y VARBINARY se truncan al final si terminan con espacios o ceros. Las columnas CHAR y BINARY, por su parte, mantienen su comportamiento de relleno, pero los efectos secundarios en columnas NULL o con valores dinámicos pueden ser impredecibles.

Un ejemplo concreto:

SET ANSI_PADDING OFF;
CREATE TABLE TestPadding (
    Codigo VARCHAR(10) NULL
);

INSERT INTO TestPadding VALUES ('ABC     ');  -- puede truncarse a 'ABC'

Este comportamiento puede parecer inocuo, pero si más adelante se cambia a ANSI_PADDING ON, las futuras inserciones pueden almacenarse de forma distinta, provocando inconsistencias en datos, índices o comparaciones.

Impacto permanente en la definición de tablas e índices

Uno de los efectos menos conocidos de ANSI_PADDING es que su estado queda grabado en la definición de la columna. Si creamos una tabla con ANSI_PADDING OFF, incluso si lo activamos después, las columnas seguirán comportándose como si estuviera desactivado.

Podemos comprobarlo en cualquier tabla con la vista de sistema sys.columns:

SELECT name, is_ansi_padded
FROM sys.columns
WHERE object_id = OBJECT_ID('dbo.MiTabla');

Una vez definida, la única forma de modificar el comportamiento de una columna con ANSI_PADDING incorrecto es eliminarla y volver a crearla.

Prácticas recomendadas al trabajar con ANSI_NULLS y ANSI_PADDING

En proyectos de larga duración, donde la compatibilidad, la trazabilidad y el rendimiento son críticos, lo más recomendable es activar siempre ambas opciones antes de crear cualquier objeto persistente:

SET ANSI_NULLS ON;
SET ANSI_PADDING ON;
GO

Esto garantiza que las definiciones serán compatibles con futuras versiones de SQL Server, con funcionalidades avanzadas como replicación o índices filtrados, y que se alinearán con el comportamiento ANSI estándar esperado por herramientas y desarrolladores.

Consideraciones adicionales en SQL Server Agent con ANSI_NULLS y ANSI_PADDING

Al igual que ocurre con QUOTED_IDENTIFIER, cuando se ejecutan scripts T-SQL desde un job de SQL Server Agent, las opciones ANSI_NULLS y ANSI_PADDING se encuentran desactivadas por defecto. Esto puede suponer un problema importante si el script crea objetos que dependen de esas configuraciones. Por tanto, es imprescindible establecerlas explícitamente al comienzo del script del paso del job:

SET ANSI_NULLS ON;
SET ANSI_PADDING ON;
GO
– resto de código del job

De esta forma evitamos errores como: “Cannot create index on column because it does not allow NULL comparisons using IS NULL” o “Column cannot be part of index because ANSI_PADDING is OFF”

Conclusión

Tanto ANSI_NULLS como ANSI_PADDING son opciones fundamentales en el desarrollo y mantenimiento de bases de datos en SQL Server. Aunque puedan parecer detalles menores, su impacto es profundo y permanente en los objetos que se crean bajo su contexto.

Activarlas de forma sistemática es una buena práctica que garantiza compatibilidad, coherencia de datos y aprovechamiento de las funcionalidades modernas del motor. Como en otros aspectos del diseño de bases de datos, los pequeños detalles marcan la diferencia entre un sistema robusto y uno plagado de sorpresas silenciosas.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Una de las opciones de configuración menos comprendidas, pero no por ello menos importantes, en SQL Server es QUOTED_IDENTIFIER. A menudo la encontramos en los scripts generados por Management Studio, en procedimientos almacenados o al realizar tareas de mantenimiento, pero, por experiencia, rara vez se le presta la atención que realmente merece. En este artículo vamos a analizar en profundidad qué es QUOTED_IDENTIFIER, cómo afecta al comportamiento de nuestras consultas T-SQL y por qué es esencial conocer su implicación en entornos complejos.

Introducción a QUOTED_IDENTIFIER: ¿Qué hace realmente?

La opción QUOTED_IDENTIFIER determina cómo SQL Server interpreta las comillas dobles («) en una consulta T-SQL. Cuando esta opción está activada, las comillas dobles delimitan identificadores (por ejemplo, nombres de columnas o tablas), permitiendo el uso de palabras reservadas o caracteres especiales. Por el contrario, si la opción está desactivada, las comillas dobles se interpretan como literales de cadena, lo que puede romper código que dependa de identificadores entrecomillados.

El comportamiento predeterminado de SQL Server desde versiones muy tempranas es tener QUOTED_IDENTIFIER activado. Sin embargo, todavía es posible desactivarla explícitamente, y ahí es donde empiezan las particularidades.

QUOTED_IDENTIFIER ON: el estándar ANSI al que estamos acostumbrados

Cuando QUOTED_IDENTIFIER está activado, se siguen las reglas ANSI SQL: las comillas dobles delimitan identificadores, y las cadenas de texto deben ir entre comillas simples (‘). Esto permite, por ejemplo, crear una columna llamada «select» o «Column With Spaces» sin que el motor se queje por el uso de palabras reservadas o caracteres especiales.

Podemos ver este comportamiento claramente:

SET QUOTED_IDENTIFIER ON;
CREATE TABLE dbo."select" (
    "Column With Spaces" INT
);

Además, algunas funcionalidades de SQL Server, como los índices XML, las columnas calculadas indexadas o las consultas distribuidas, requieren explícitamente que QUOTED_IDENTIFIER esté activado. Es más, al crear procedimientos almacenados, vistas, funciones o triggers, esta opción queda «grabada» junto al objeto y no puede cambiarse dinámicamente durante su ejecución.

QUOTED_IDENTIFIER OFF: compatibilidad heredada… y peligros potenciales

Cuando QUOTED_IDENTIFIER está desactivado, las comillas dobles se tratan como delimitadores de cadenas. Esto puede llevar a comportamientos inesperados si asumimos que SQL Server sigue el estándar ANSI. Por ejemplo:

SET QUOTED_IDENTIFIER OFF;
SELECT "columna" FROM dbo.Tabla; –Devuelve el literal 'columna' en todas las filas

Este comportamiento puede parecer trivial, pero en entornos donde el código se genera dinámicamente o se espera interoperabilidad con otros motores, las diferencias sintácticas pueden provocar errores difíciles de depurar.

Además, muchas características modernas del motor de SQL Server no funcionarán si QUOTED_IDENTIFIER está desactivado en el momento de crear el objeto. Un ejemplo frecuente es el intento de indexar una columna calculada:

SET QUOTED_IDENTIFIER OFF;
CREATE TABLE Test (
    Valor1 INT,
    Valor2 AS Valor1 * 2
);
CREATE INDEX idx_Test ON Test(Valor2); 

Esta consulta nos va a devolver un Error 1934 porque no es posible crear un índice en una columna calculada cuando QUOTED_IDENTIFIER está desactivado.

Objetos definidos: persistencia silenciosa

Uno de los aspectos más delicados de QUOTED_IDENTIFIER es que su valor queda almacenado con el objeto al momento de su creación. Es decir, si definimos una vista o procedimiento con QUOTED_IDENTIFIER OFF, ese valor persistirá en el objeto, aunque más tarde ejecutemos SET QUOTED_IDENTIFIER ON en sesiones posteriores.

Este hecho tiene implicaciones especialmente relevantes cuando trabajamos con funcionalidades como replicación, indexed views o columnas calculadas indexadas, ya que en muchas de estas características, SQL Server exige que QUOTED_IDENTIFIER esté activado.

Un ejemplo habitual en mantenimiento de bases de datos es encontrar procedimientos que fallan al intentar recompilarse simplemente porque fueron creados originalmente con QUOTED_IDENTIFIER OFF.

Podemos comprobar la configuración de un procedimiento almacenado de la siguiente forma:

SELECT OBJECTPROPERTY(OBJECT_ID('dbo.MiProcedimiento'), 'IsQuotedIdentOn');

Si el valor devuelto es 0, el objeto fue creado con QUOTED_IDENTIFIER OFF.

QUOTED_IDENTIFIER y ANSI_NULLS: el tándem inseparable

Cuando tratamos con buenas prácticas en la definición de objetos de base de datos, QUOTED_IDENTIFIER suele mencionarse junto a ANSI_NULLS. Y no es casualidad: ambos son requeridos por muchas de las características avanzadas de SQL Server. Las herramientas de desarrollo como Management Studio o SSDT los activan por defecto en los scripts generados, precisamente para garantizar que los objetos resultantes no estén limitados en funcionalidades futuras. Un ejemplo típico sería:

SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE dbo.MiProc
AS
BEGIN
    SELECT * FROM dbo.MiTabla;
END
GO

Comportamiento en SQL Server Agent 

Aunque en el uso interactivo de SQL Server, por ejemplo desde SQL Server Management Studio, QUOTED_IDENTIFIER suele estar activado por defecto, no ocurre lo mismo en todos los contextos. Un caso especialmente importante es la ejecución de scripts T-SQL desde pasos de tipo «Transact-SQL script (T-SQL)» en los trabajos de SQL Server Agent.

En estos pasos, la configuración predeterminada de la sesión establece QUOTED_IDENTIFIER OFF. Esto puede pasar completamente desapercibido si no se especifica manualmente la opción al inicio del script, pero las consecuencias pueden ser críticas. Cualquier intento de crear índices en columnas calculadas, vistas indexadas, procedimientos almacenados que dependan de esa opción, o incluso utilizar ciertas instrucciones que exigen la semántica ANSI, fallará silenciosamente o con errores que no apuntan directamente al problema.

Para evitarlo, es recomendable incluir explícitamente la activación de QUOTED_IDENTIFIER al inicio de cualquier script ejecutado desde SQL Server Agent, especialmente si ese script crea o modifica objetos:

SET QUOTED_IDENTIFIER ON;
GO
-- Resto del código del paso

Esta simple precaución asegura que los comportamientos esperados de la sesión se mantendrán, alineados con el desarrollo realizado en otras herramientas como SSMS o Visual Studio.

QUOTED_IDENTIFIER en flujos de trabajo DevOps y control de versiones

En escenarios donde utilizamos herramientas de CI/CD para desplegar cambios en bases de datos, la configuración de QUOTED_IDENTIFIER cobra especial relevancia. Los generadores de scripts, como SQLPackage o herramientas de despliegue como DACPACs, se apoyan en estas configuraciones para determinar si deben aplicar ciertos cambios o recrear objetos desde cero.

No es raro encontrarse con diferencias de comportamiento entre entornos debido a inconsistencias en estas opciones. Por tanto, siempre es recomendable mantener estas configuraciones explícitas y estandarizadas a lo largo del ciclo de vida del desarrollo.

QUOTED_IDENTIFIER y el rendimiento: ¿hay impacto?

Aunque QUOTED_IDENTIFIER no afecta directamente al plan de ejecución o a la eficiencia de una consulta, sí tiene un impacto indirecto. Como hemos mencionado, su estado condiciona el uso de columnas calculadas indexadas, vistas indexadas y otras estructuras que sí mejoran el rendimiento. Por tanto, mantener esta opción activada es esencial para no limitar las posibilidades de optimización que ofrece SQL Server.

Conclusión

A estas alturas parece evidente: en la mayoría de los escenarios, debemos trabajar con QUOTED_IDENTIFIER ON. No solo garantiza compatibilidad con las funcionalidades modernas del motor de SQL Server, sino que evita ambigüedades y errores sutiles cuando se manipulan identificadores que contienen caracteres especiales o palabras reservadas.

Los únicos contextos en los que podríamos considerar desactivarlo son aquellos de compatibilidad con aplicaciones muy antiguas o migraciones específicas donde el código ya existente lo exige. Fuera de esos casos, es una práctica segura y recomendada mantener QUOTED_IDENTIFIER activado en todas nuestras sesiones y scripts.

Para cerrar, si queremos asegurarnos de que todos nuestros objetos han sido creados con QUOTED_IDENTIFIER ON, conviene hacer una auditoría periódica en nuestros entornos y revisar su uso, especialmente si trabajamos con desarrolladores múltiples o heredamos bases de datos legacy.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!