No GO : Peut-on éviter d'utiliser GO dans les scripts T-SQL ?

Hello !
Hier soir en lisant un e-book intitulé "Defensive_Database_Programming", j'ai voulu tester un bout de code en faisant un copier/coller du code depuis la page .pdf vers SQL Server Management Studio (ssms). Après une indentation rapide, j'exécute le code mais sans succès ! [rassurez-vous le code est correct ;)]
Au fait c'était un "GO" qui trainait sur la même ligne qu'une instruction.
Et celà => perte de temps.
Je me suis dit que je ne suis pas le 1er à qui celà arrive et que ça va sûrement arriver à d'autre. J'ai fait un petit papier sur "GO" afin de montrer les pièges à éviter !

Ma question : Etant donné que GO n'est pas une commande T-SQL, nos
========
instrustions T-SQL ont-elles besoin de GO pour marcher ?! Pourquoi voit-on des codes avec des GO partout ?

Je comprends qu'en mode interactif avec sqlcmd par exemple qu'on ait besoin de GO pour donner l'ordre à l'utilitaire d'envoyer une instrustion au moteur SQL

Mais en dehors de ces cas quelles peuvent être l'utilité de GO ?

Merci de m'éclairer ;)

Plusieurs cas d'utilisation du GO :

- Permet d'isoler le contexte de chaque portion de code et leurs variables. La portée d'une variable n'est alors valable que depuis le début du code ou la fin du GO à un autre GO

- Permet de pouvoir créer des objets dans un seul fichier. Si tu livres un fichier avec plusieurs objets à créer, il faudra bien les démarquer par un GO.

++

Citation:

---

Envoyé par mikedavem

Plusieurs cas d'utilisation du GO :

- Permet d'isoler le contexte de chaque portion de code et leurs variables. La portée d'une variable n'est alors valable que depuis le début du code ou la fin du GO à un autre GO

---

Pour la portée des variables, T-SQL permet de bien les gérer sans faire appel à des GO. J'ai montré dans mon papier un moyen de les éviter

Citation:

---

- Permet de pouvoir créer des objets dans un seul fichier. Si tu livres un fichier avec plusieurs objets à créer, il faudra bien les démarquer par un GO.
++

---

As-tu un exemple concret ? J'aimerais bien voir un exemple concret de code T-SQL qui nécessite l'usage de GO (exclu l'usage des utilitaires SQL Server en mode interactif) ! ça m'interesse ;)

Citation:

---

As-tu un exemple concret ? J'aimerais bien voir un exemple concret de code T-SQL qui nécessite l'usage de GO (exclu l'usage des utilitaires SQL Server en mode interactif) ! ça m'interesse

---

Oui .. prenons l'exemple d'un fichier sql qui te livre différentes procédure stockées d'une application .. sans les GO cela donne :

Code:

---

1 2 3 4 5 6 7 8

CREATE PROCEDURE test AS SELECT @@VERSION   CREATE PROCEDURE test2 AS SELECT @@VERSION

---

Bien entendu ce code ne fontionnera pas. Il faut évidemment mettre un GO pour délimiter les 2 procédure stockées.

Citation:

---

Pour la portée des variables, T-SQL permet de bien les gérer sans faire appel à des GO. J'ai montré dans mon papier un moyen de les éviter

---

La solution que tu proposes (NO GO) n'isole pas une variable ... c'est simplement l'écriture correcte du code. Si je prends ton exemple adapté pour ce cas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

DECLARE @MESSAGE VARCHAR(50) SET @MESSAGE = 'Test de la règle N°2' PRINT @MESSAGE   -- GO ---------   SET @MESSAGE = 1.5 PRINT @MESSAGE + 1   GO

---

Il ne suffira pas d'enlever le GO et de le mettre à la fin dans ce cas. Exemple vraiment simplissime je l'avoue ..

Enfin le GO te permet également de répéter l'exécution de code N fois

Code:

---

1 2	INSERT matable VALUES ('text') GO 500

---

++

Citation:

---

Envoyé par mikedavem

Oui .. prenons l'exemple d'un fichier sql qui te livre différentes procédure stockées d'une application .. sans les GO cela donne :

Code:

---

1 2 3 4 5 6 7 8

CREATE PROCEDURE test AS SELECT @@VERSION   CREATE PROCEDURE test2 AS SELECT @@VERSION

---

Bien entendu ce code ne fontionnera pas. Il faut évidemment mettre un GO pour délimiter les 2 procédure stockées.

---

Voici une solution NO GO : Règle N° 3

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

EXECUTE (' CREATE PROCEDURE test AS SELECT @@VERSION ')   EXECUTE (' CREATE PROCEDURE test2 AS SELECT @@VERSION ')

---

Citation:

---

La solution que tu proposes (NO GO) n'isole pas une variable ... c'est simplement l'écriture correcte du code. Si je prends ton exemple adapté pour ce cas :

Code:

---

1 2 3 4 5 6 7 8

DECLARE @MESSAGE VARCHAR(50) SET @MESSAGE = 'Test de la règle N°2' PRINT @MESSAGE -- GO --------- SET @MESSAGE = 1.5 PRINT @MESSAGE + 1 GO

---

Il ne suffira pas d'enlever le GO et de le mettre à la fin dans ce cas. Exemple vraiment simplissime je l'avoue ..

---

C'est un oublie :). En supprimant aussi le GO de la fin celà ne change rien de l'exemple ... Essaye ;)

Citation:

---

Enfin le GO te permet également de répéter l'exécution de code N fois

Code:

---

1 2	INSERT matable VALUES ('text') GO 500

---

++

---

ça je l'ai dit aussi dans mon papier. Voir règle N°4 ;)

Citation:

---

EXECUTE ('
CREATE PROCEDURE test
AS
SELECT @@VERSION
')

EXECUTE ('
CREATE PROCEDURE test2
AS
SELECT @@VERSION
')

---

Oui c'est une possibilité mais je ne vois pas l'intérêt à faire cela mis à part rendre le code plus complexe. L'instruction GO est beaucoup plus pratique dans ce cas.

Citation:

---

C'est un oublie . En supprimant aussi le GO de la fin celà ne change rien de l'exemple ... Essaye

---

Si tu parles de mon exemple ou du tiens effectivement ca ne change rien. disons que le GO + une déclaration double de la variable sera nécessaire. On aura dans ce cas une portion de code vraimet isolée par rapport l'autre. C'est l'intérêt en fait.

--

En rapport avec ta solution pour creer des stored procedures en chaine en utilisant execute, effectivement c'est une solution...
Par contre vive les erreurs potentielles et l'amusement pour doubler tous les potentiels ' ' se trouvant dans la stored procedure.

Citation:

---

Envoyé par mikedavem

Oui c'est une possibilité mais je ne vois pas l'intérêt à faire cela mis à part rendre le code plus complexe. L'instruction GO est beaucoup plus pratique dans ce cas.

---

L'intérêt peut être d'éviter des problèmes avec la commande GO !
Le Book Online dit ceci :
"Les applications basées sur ODBC ou sur les API OLE DB reçoivent une erreur de syntaxe s'ils tentent d'exécuter une commande GO"

Ce qui me gêne aussi un peu c'est le fait que GO ne soit pas une commande T-SQL mais s'incruste partout ! même dans les requêtes les simples (non batch) .

D'où l'idée du No GO

Citation:

---

Envoyé par Ptit_Dje

En rapport avec ta solution pour creer des stored procedures en chaine en utilisant execute, effectivement c'est une solution...
Par contre vive les erreurs potentielles et l'amusement pour doubler tous les potentiels ' ' se trouvant dans la stored procedure.

---

C'est vrai Go est plus simple est permet plus de lisibilité du code.

Mais si l'idée est de faire tourner un même script sur différentes applications, il peut être interessante de sans que la solution No GO existe car je cite à nouveau le Book Online :
"Les applications basées sur ODBC ou sur les API OLE DB reçoivent une erreur de syntaxe s'ils tentent d'exécuter une commande GO"

Citation:

---

Mais si l'idée est de faire tourner un même script sur différentes applications, il peut être interessante de sans que la solution No GO existe car je cite à nouveau le Book Online :
"Les applications basées sur ODBC ou sur les API OLE DB reçoivent une erreur de syntaxe s'ils tentent d'exécuter une commande GO"

---

Pour en revenir au GO il est évident que si tu utilises de tels api il faudra adapter mais personnellement je trouve qu'il sera bcp plus efficace de faire tourner des scripts nécéssitant le GO via une sessions sqlcmd par exemple que de faire du bricolage pour absolument les éviter

++

Je ne vois pas où tu veux venir avec ce post en fait

Citation:

---

L'intérêt peut être d'éviter des problèmes avec la commande GO !
Le Book Online dit ceci :
"Les applications basées sur ODBC ou sur les API OLE DB reçoivent une erreur de syntaxe s'ils tentent d'exécuter une commande GO"

---

.

Qui mettrait des GO dans une appli ODBC/OLE DB ? Pas grand monde
Tu utilises dans des GO dans des scripts que tu vas lancer avec SSMS ou SQLCMD, c'est tout je pense..... à moins que tu aies un lanceur de scripts codé en .net qui utilises ODBC ou OLEDB (mais ça serait un peu tordu).

La commande GO est là depuis belle lurette et je ne vois pas oú est le problème.

Citation:

---

Envoyé par mikedavem

Pour en revenir au GO il est évident que si tu utilises de tels api il faudra adapter mais personnellement je trouve qu'il sera bcp plus efficace de faire tourner des scripts nécéssitant le GO via une sessions sqlcmd par exemple que de faire du bricolage pour absolument les éviter

++

---

Je suis d'accord pour ton idée de passer par sqlcmd pour faire tourner un script contenant Go et l'adapter à toute application.

Et là on se rend compte de l'importance de l'intrus GO dans nos scripts T-SQL !!!

Qu'une commande SQL joue le même rôle que GO ne me dérange pas, mais qu'est ce qui explique qu'il y a pas d'équivalent de Go en T-SQL ?

Tiens , le BEGIN par exemple donne le signal de départ d'un traitement au moteur SQL et pourtant BEGIN c'est du SQL ? Non ?

Merci de m'éclairer ;)

Citation:

---

Tiens , le BEGIN par exemple donne le signal de départ d'un traitement au moteur SQL et pourtant BEGIN c'est du SQL ? Non ?

---

BEGIN est une instruction de contrôle de flux qui permet une exécution groupée d'un ensemble de code. Il n'a pas la même vocation que l'instruction GO

++

Citation:

---

Envoyé par kagemaru

Je ne vois pas où tu veux venir avec ce post en fait -

---

++

GO n'est pas une commande SQL. C'est une commande de l'interpréteur de commande qu'est selon le cas, SQL Server Management Studio ou SQMCMD...
Cela permet aux commandes bufferisées d'être envoyées pour exécution au serveur SQL

Tous les SGBDR ont une commande équivalente. Certains permettent de paramétrer cette commande.
Par exemple :

• pour Oracle c'est RUN ou /
• Pour Interbase, vous avez le choix du caractères qui paramètre ce lancement.

Certaines commandes SQL ne sont pas compatibles entre elles.
Par exemple vous ne pouvez pas créer une vue sans un GO préalable, sauf si cette commande est la seule ou se trouve encapsulée dans un CREATE SCHEMA.

A +

Citation:

---

Envoyé par SQLpro

Par exemple vous ne pouvez pas créer une vue sans un GO préalable, sauf si cette commande est la seule ou se trouve encapsulée dans un CREATE SCHEMA.
A +

---

Je ne suis pas d'accord. On en avait discuter plus haut.

Voici un exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

EXECUTE (' CREATE VIEW v_test1 AS SELECT @@VERSION [Version] ')   EXECUTE (' CREATE VIEW v_test2 AS SELECT @@VERSION [Version] ')

---

Cela revient à être la seule commande du lot, car chaque EXECUTE est lancé en dehors du contexte.

A +