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

Question

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?

Answer 1

Desde un SQLServerCentral.Com article por Ken Powers:

el punto y coma

El punto y coma es un terminador de la sentencia. 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 utilizar 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 declaración de Service Broker y la declaración de Service Broker no es la primera declaración en el lote.

Answer 2

De forma predeterminada, 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 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, lo 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 aquellos que dicen que los terminadores de sentencias no son requeridos por [RDBMS particular], mientras que eso puede ser cierto, son requeridos por el ANSI SQL Standard. 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 solo proveedor.

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

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 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.

Answer 3

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

Dado que el compilador no los requiere, usted puede ponerlos de nuevo, pero ¿por qué? El compilador 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, como 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 

Answer 4

En SQL2008 BOL dicen que en próximas versiones serán requeridos punto y coma. Por lo tanto, siempre úselo.

Referencia:

• Transact-SQL Syntax Conventions (Transact-SQL)
• Deprecated Database Engine Features in SQL Server 2008 R2 ("no compatibles en una versión futura de SQL Server", área "Transact-SQL")

Answer 5

Parece que punto y coma debe no se debe usar 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 sintaxis para estas declaraciones de cursor.

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

Pero: OPEN mycursor trabajado.

Answer 6

Al usar una instrucción DISABLE o ENABLE TRIGGER en un lote que tiene otras instrucciones, la instrucción justo antes debe terminar con un punto y coma. De lo contrario, obtendrá un error de sintaxis. 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 here

Answer 7

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

EDIT: me encontré con un plug-in para SSMS 2008R2 que formatear el guión y añadir los puntos y comas. Creo que todavía está en fase beta, aunque ...

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

EDIT: he encontrado una herramienta aún mejor, libre/plugin llamado ApexSQL ... http://www.apexsql.com/

Answer 8

punto y coma no siempre funcionan en el compuesto Instrucciones SELECT

Compara estas dos versiones diferentes de una instrucció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; 

devuelve

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

obstante, el código

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

rendimientos

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

(1 row(s) affected) 

Answer 9

Usted debe usarlo.

La práctica de utilizar un punto y coma para terminar las instrucciones 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, el uso de 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 ahorrar . (Cuando se requiere un punto y coma y no se especifica, el SQL mensaje de error produce servidor no siempre es muy clara.)

Y lo más importante:

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

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

---

Un ejemplo de eso que siempre se debe utilizar ; son las siguientes dos consultas (copiadas de este post):

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 

Answer 10

todavía tiene 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 instrucció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 tuve la transacción funcionando de la manera que quería, decidí ponerle un try-catch, así que si hay algún error, se retrotrae.Sólo después de hacer esto, la transacción no se cometió (SSMS confirma esto cuando se trata de cerrar la ventana con un mensaje que le advierte sobre el hecho de que hay una transacción no confirmada.

Así que este

COMMIT TRANSACTION 

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

COMMIT TRANSACTION; 

cuenta que no hay error o aviso proporcionado y no hay indicación de que la transacción es no comprometidos hasta intentar cerrar el que pestaña ry.

Afortunadamente, esto causa un problema tan grande que es inmediatamente obvio que hay un problema. Lamentablemente, dado que no se informa ningún error (sintaxis 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.

Answer 11

Nota: Esto responde la pregunta tal como está escrita, pero no el problema como se indica. La adición de aquí, ya que las personas estarán buscando para ello

punto y coma se utiliza también en los estados antes WITH 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 Números compuesta por enteros [1 .. 10]. Se lleva a cabo mediante la creación de una tabla con el valor 1, y después de manera recursiva hasta llegar a 10.

Answer 12

Según Transact-SQL Syntax Conventions (Transact-SQL) (MSDN)

terminador instrucción de 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.

(ver también @gerryLowry 's comentario)

Answer 13

Si te gusta conseguir al azar límite de comando errores en SQL Server a continuación, dejar fuera el punto y coma al final de sus cuerdas CommandText.

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

tengo ejemplos verificables y reproducibles utilizando SQL Server 2008.

aka ->En la práctica, siempre incluyen el terminador incluso si acaba de enviar una declaración a la base de datos.