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

para que sirve el punto en sql

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

Cuando se usa una instrucción DISABLE o ENABLE TRIGGER en un lote que tiene otras declaraciones, la declaració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 2

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

Terminador de la declaración 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)

Answer 3

De un article 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 declaración de Service Broker y la declaración de Service Broker no es la primera declaración en el lote.

Answer 4

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 objetivo 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 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 5

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

Referencia:

• Convenciones de sintaxis 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")

Answer 6

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

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)

Answer 7

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 sintaxis para estas declaraciones de cursor.

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

Pero: OPEN mycursor funcionó.

Answer 8

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 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 sentencia no son requeridos por [RDBMS particular], mientras que 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 solo proveedor.

Con algunos compiladores 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 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 9

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 declaración a la base de datos.

Answer 10

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/

Answer 11

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 y otros sitios) encontré un caso donde parece que se necesita 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 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 (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 12

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.

Answer 13

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

Dado que el compilador no los requiere, puede ponerlos por todos lados, 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, 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