¿Cuándo debo usar punto y coma en SQL Server?

Al verificar algunos códigos en la web y los scripts generados por SQL Server Management Studio, noté que algunas declaraciones terminan en punto y coma.

Entonces, ¿cuándo debo usarlo?

De un artículo de SQLServerCentral.Com de Ken Powers:

El punto y coma

El carácter de punto y coma es un terminador de declaración. Es parte del estándar ANSI SQL-92, pero nunca se usó dentro de Transact-SQL. De hecho, fue posible codificar T-SQL durante años sin encontrar nunca un punto y coma.

Uso

Hay dos situaciones en las que debe usar el punto y coma. La primera situación es donde utiliza una expresión de tabla común (CTE), y el CTE no es la primera instrucción del lote. El segundo es donde emite una declaración de Service Broker y la declaración de Service Broker no es la primera declaración del lote.

Por defecto, las sentencias SQL terminan con punto y coma. Utiliza un punto y coma para terminar las declaraciones a menos que haya (rara vez) establecido un nuevo terminador de declaraciones.

Si envía una sola declaración, técnicamente puede prescindir del terminador de la declaración; en un script, ya que está enviando más de una declaración, la necesita.

En la práctica, siempre incluya el terminador incluso si solo está enviando una declaración a la base de datos.

Editar: en respuesta a los que dicen que los terminadores de declaraciones no son requeridos por [RDBMS particular], aunque eso puede ser cierto, son requeridos por el Estándar ANSI SQL. En toda la programación, si podemos adherirnos a un Estándar sin pérdida de funcionalidad, deberíamos hacerlo, porque entonces ni nuestro código ni nuestros hábitos están vinculados a un proveedor propietario.

Con algunos compiladores de C, es posible tener main return anular, aunque el estándar requiere que main regrese int. Pero hacerlo hace que nuestro código, y nosotros mismos, sea menos portátil.

La mayor dificultad en la programación efectiva no es aprender cosas nuevas, es desaprender los malos hábitos. En la medida en que podamos evitar adquirir malos hábitos en primer lugar, es una victoria para nosotros, para nuestro código y para cualquiera que lea o use nuestro código.

En SQL2008 BOL dicen que en las próximas versiones se requerirán puntos y comas. Por lo tanto, úsalo siempre.

Referencia:

• Convenciones de sintaxis de Transact-SQL (Transact-SQL)
• Características obsoletas del motor de base de datos en SQL Server 2008 R2 (sección "Características no admitidas en una versión futura de SQL Server", área "Transact-SQL")

Usted debe usarlo.

La práctica de usar un punto y coma para terminar las declaraciones es estándar y, de hecho, es un requisito en varias otras plataformas de bases de datos. SQL Server requiere el punto y coma solo en casos particulares, pero en los casos en que no se necesita un punto y coma, el uso de uno no causa problemas. Le recomiendo que adopte la práctica de terminar todas las declaraciones con punto y coma. Esto no solo mejorará la legibilidad de su código, sino que en algunos casos puede ahorrarle algo de pena. (Cuando se requiere un punto y coma y no se especifica, el mensaje de error que produce SQL Server no siempre es muy claro).

Y lo más importante:

La documentación de SQL Server indica que no terminar las sentencias T-SQL con un punto y coma es una característica obsoleta. Esto significa que el objetivo a largo plazo es forzar el uso del punto y coma en una versión futura del producto. Esa es una razón más para adquirir el hábito de terminar todas sus declaraciones, incluso donde actualmente no se requiere.

Fuente: Microsoft SQL Server 2012 T-SQL Fundamentals de Itzik Ben-Gan.

Un ejemplo de por qué siempre debe usar ;son las siguientes dos consultas (copiadas de esta publicación ):

BEGIN TRY
    BEGIN TRAN
    SELECT 1/0 AS CauseAnException
    COMMIT
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE()
    THROW
END CATCH

BEGIN TRY
    BEGIN TRAN
    SELECT 1/0 AS CauseAnException;
    COMMIT
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE();
    THROW
END CATCH

Si leo esto correctamente, será un requisito usar puntos y comas para finalizar las instrucciones TSQL. http://msdn.microsoft.com/en-us/library/ms143729%28v=sql.120%29.aspx

EDITAR: Encontré un complemento para SSMS 2008R2 que formateará su script y agregará los puntos y comas. Aunque creo que todavía está en beta ...

http://www.tsqltidy.com/tsqltidySSMSAddin.aspx

EDITAR: encontré una herramienta / complemento gratuito aún mejor llamado ApexSQL ... http://www.apexsql.com/

Opinión personal: Úselos solo donde se requieran. (Consulte la respuesta de TheTXI arriba para ver la lista requerida).

Como el compilador no los requiere, puedes ponerlos todos, pero ¿por qué? El compilador no le dirá dónde olvidó uno, por lo que terminará con un uso inconsistente.

[Esta opinión es específica de SQL Server. Otras bases de datos pueden tener requisitos más estrictos. Si está escribiendo SQL para ejecutarse en múltiples bases de datos, sus requisitos pueden variar.]

tpdi declaró anteriormente, "en un script, ya que está enviando más de una declaración, la necesita". Eso en realidad no es correcto. No los necesitas.

PRINT 'Semicolons are optional'
PRINT 'Semicolons are optional'
PRINT 'Semicolons are optional';
PRINT 'Semicolons are optional';

Salida:

Semicolons are optional
Semicolons are optional
Semicolons are optional
Semicolons are optional

Todavía tengo mucho que aprender sobre T-SQL, pero al elaborar un código para una transacción (y basar el código en ejemplos de stackoverflow y otros sitios) encontré un caso en el que parece que se requiere un punto y coma y si falta, la declaración no parece ejecutarse en absoluto y no se genera ningún error. Esto no parece estar cubierto en ninguna de las respuestas anteriores. (Esto estaba usando MS SQL Server 2012.)

Una vez que hice que la transacción funcionara de la manera que quería, decidí ponerle un try-catch para que, si hay algún error, se revierta. Solo después de hacer esto, la transacción no se confirmó (SSMS lo confirma al intentar cerrar la ventana con un mensaje agradable que le alerta sobre el hecho de que hay una transacción no confirmada.

Así que esto

COMMIT TRANSACTION 

fuera de un bloque BEGIN TRY / END TRY funcionó bien para confirmar la transacción, pero dentro del bloque tenía que ser

COMMIT TRANSACTION;

Tenga en cuenta que no se proporciona ningún error o advertencia y no hay indicación de que la transacción aún no se haya confirmado hasta que intente cerrar la pestaña de consulta.

Afortunadamente, esto causa un problema tan grande que es inmediatamente obvio que hay un problema. Desafortunadamente, dado que no se informa ningún error (sintaxis o de otro tipo), no era inmediatamente obvio cuál era el problema.

Por el contrario, la TRANSACCIÓN ROLLBACK parece funcionar igualmente bien en el bloque BEGIN CATCH con o sin punto y coma.

Puede haber algo de lógica en esto, pero se siente arbitrario y Alicia en el país de las maravillas.

Parece que punto y coma no deben ser utilizados en conjunción con operaciones de cursor: OPEN, FETCH, CLOSEyDEALLOCATE . Acabo de perder un par de horas con esto. ¡Observé de cerca el BOL y noté que [;] no se muestra en la sintaxis de estas instrucciones de cursor!

Entonces tuve:

OPEN mycursor;

y esto me dio el error 16916.

Pero:

OPEN mycursor

trabajó.

Según las convenciones de sintaxis de Transact-SQL (Transact-SQL) (MSDN)

Terminador de instrucción Transact-SQL. Aunque el punto y coma no se requiere para la mayoría de las declaraciones en esta versión de SQL Server, se requerirá en una versión futura.

(también vea el comentario de @gerryLowry)

Cuando se utiliza una instrucción DISABLE o ENABLE TRIGGER en un lote que contiene otras instrucciones, la instrucción justo antes de que finalice con un punto y coma. De lo contrario, obtendrá un error de sintaxis. Me arranqué el pelo con este ... Y luego, me topé con este artículo de MS Connect sobre lo mismo. Está cerrado ya que no se arreglará.

mira aquí

Nota: Esto responde la pregunta tal como está escrita, pero no el problema como se indicó. Agregándolo aquí, ya que la gente lo buscará

El punto y coma también se usa antes WITHen las declaraciones recursivas de CTE:

;WITH Numbers AS
(
    SELECT n = 1
    UNION ALL
    SELECT n + 1
    FROM Numbers
    WHERE n+1 <= 10
)
SELECT n
FROM Numbers

Esta consulta generará un CTE llamado Números que consta de enteros [1..10]. Se realiza creando una tabla con el valor 1 solamente, y luego recurriendo hasta llegar a 10.

Si te gusta obtener un tiempo de espera de comando aleatorio errores en SQLServer, deje el punto y coma al final de las cadenas de CommandText.

No sé si esto está documentado en alguna parte o si es un error, pero sucede y lo he aprendido por amarga experiencia.

Tengo ejemplos verificables y reproducibles usando SQLServer 2008.

aka -> En la práctica, siempre incluya el terminador incluso si solo está enviando una declaración a la base de datos.

Los punto y coma no siempre funcionan en sentencias SELECT compuestas.

Compare estas dos versiones diferentes de una declaración SELECT compuesta trivial.

El código

DECLARE @Test varchar(35); 
SELECT @Test=
    (SELECT 
        (SELECT 
            (SELECT 'Semicolons do not always work fine.';););); 
SELECT @Test Test;

devoluciones

Msg 102, Level 15, State 1, Line 5
Incorrect syntax near ';'.

Sin embargo, el código

DECLARE @Test varchar(35)
SELECT @Test=
    (SELECT 
        (SELECT 
            (SELECT 'Semicolons do not always work fine.'))) 
SELECT @Test Test

devoluciones

Test
-----------------------------------
Semicolons do not always work fine.

(1 row(s) affected)