Discussion :

[zinzineti]

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

[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

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

++

[zinzineti]

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

- 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

[mikedavem]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

++

[zinzineti]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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
')

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

++

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

[mikedavem]

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.

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.

--

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