¿Cuándo debería usar punto y coma en SQL Server?

Al revisar algunos códigos en la web y los scripts generados por SQL Server Management Studio, he notado que algunas declaraciones terminan con un punto y coma.

Entonces, ¿cuándo debería usarlo?

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

El punto y coma

El carácter de punto y coma es un terminador de enunciado. Es parte del estándar ANSI SQL-92, pero nunca se utilizó en Transact-SQL. De hecho, fue posible codificar T-SQL durante años sin encontrar 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 en el lote. El segundo es donde se emite una statement de Service Broker y la statement de Service Broker no es la primera statement en el lote.

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

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

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

Editar: en respuesta a aquellos que dicen que los terminadores de sentencia no son requeridos por [RDBMS particular], mientras que eso puede ser cierto, son requeridos por el estándar ANSI SQL. En toda la progtwigció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 solo proveedor.

Con algunos comstackdores de C, es posible tener un retorno de retorno principal, aunque el Estándar requiere que main devuelva int. Pero al hacerlo, nuestro código y nosotros mismos somos menos portátiles.

La mayor dificultad en la progtwigción efectiva no es aprender cosas nuevas, es desaprender los malos hábitos. En la medida en que podamos evitar la adquisición de malos hábitos en primer lugar, es una victoria para nosotros, para nuestro código y para cualquier persona 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, siempre úselo.

Referencia:

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

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

EDITAR: Encontré un complemento para SSMS 2008R2 que formateará tu secuencia de comandos y agregará los puntos y comas. Creo que todavía está en beta, aunque …

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

EDIT: encontré una herramienta / complemento aún mejor llamada ApexSQL … http://www.apexsql.com/

Debes usarlo

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

Y lo más importante:

La documentación de SQL Server indica que no terminar las sentencias de T-SQL con un punto y coma es una característica en desuso. Esto significa que el objective a largo plazo es imponer 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 cuando en este momento no se requiere.

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


Un ejemplo de por qué siempre debes usar ; son las dos consultas siguientes (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 

enter image description here

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

enter image description here

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

Dado que el comstackdor no los requiere, puede ponerlos por todos lados, pero ¿por qué? El comstackdor no le dirá dónde lo olvidó, 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 ejecutar en múltiples bases de datos, sus requisitos pueden variar.]

tpdi declaró anteriormente, “en un guión, ya que está enviando más de una statement, 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 trabajar con algún código para una transacción (y basar código en ejemplos de stackoverflow y otros sitios) encontré un caso donde parece que se necesita un punto y coma y, si falta, la statement 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 hubiera algún error, se revierte. Solo después de hacer esto, la transacción no se confirmó (SSMS confirma esto al intentar cerrar la ventana con un bonito mensaje que lo 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 comprometer 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 indicios de que la transacción aún no esté comprometida hasta que se intente cerrar la pestaña de consulta.

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

Por el contrario, ROLLBACK TRANSACTION parece funcionar igual de 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.

De acuerdo con las convenciones de syntax de Transact-SQL (Transact-SQL) (MSDN)

Terminador de la statement Transact-SQL. Aunque el punto y coma no es necesario para la mayoría de las declaraciones en esta versión de SQL Server, será necesario en una versión futura.

(también vea el comentario de @gerryLowry)

Parece que los puntos y comas no deben usarse junto con las operaciones del cursor: ABRIR, ABRIR, CERRAR y DESARMAR. Solo perdí un par de horas con esto. Eché un vistazo de cerca al BOL y noté que [;] no se muestra en la syntax para estas declaraciones de cursor.

Así que tuve: OPEN mycursor; y esto me dio el error 16916.

Pero: OPEN mycursor funcionó.

Los puntos y coma no siempre funcionan en las declaraciones compuestas SELECT.

Compare estas dos versiones diferentes de una statement 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) 

Cuando se usa una instrucción DISABLE o ENABLE TRIGGER en un lote que tiene otras declaraciones, la statement justo antes debe terminar con un punto y coma. De lo contrario, obtendrá un error de syntax. Me arranqué el pelo con este … Y después, tropecé con este artículo de MS Connect sobre lo mismo. Está cerrado como no se arregla.

ver aquí

Nota: Esto responde la pregunta tal como está escrita, pero no el problema tal como se establece. Agregándolo aquí, ya que las personas lo estarán buscando

Semicolon también se usa antes de WITH en declaraciones CTE recursivas:

 ;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 Numbers que consta de enteros [1..10]. Se hace creando una tabla con el valor 1 solamente, y luego recurriendo hasta llegar a 10.

Si desea obtener errores aleatorios de Tiempo de espera de comando en SQLServer, deje el punto y coma al final de las cadenas de texto de CommandText.

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

Tengo ejemplos verificables y reproducibles usando SQLServer 2008.

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