IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

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


Sujet :

Administration SQL Server

  1. #1
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut 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
    Etienne ZINZINDOHOUE
    Billets-Articles

  2. #2
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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.

    ++

  3. #3
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    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
    Etienne ZINZINDOHOUE
    Billets-Articles

  4. #4
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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
    ++

  5. #5
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    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
    Etienne ZINZINDOHOUE
    Billets-Articles

  6. #6
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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.

    --

  7. #7
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Août 2007
    Messages : 1 216
    Par défaut
    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.

  8. #8
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    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
    Etienne ZINZINDOHOUE
    Billets-Articles

  9. #9
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par Ptit_Dje Voir le message
    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"
    Etienne ZINZINDOHOUE
    Billets-Articles

  10. #10
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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

    ++

  11. #11
    Membre Expert
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    1 056
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 1 056
    Par défaut
    Je ne vois pas où tu veux venir avec ce post en fait

    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.

  12. #12
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    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
    Etienne ZINZINDOHOUE
    Billets-Articles

  13. #13
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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

    ++

  14. #14
    Membre émérite
    Profil pro
    Inscrit en
    Février 2008
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 758
    Par défaut
    Citation Envoyé par kagemaru Voir le message
    Je ne vois pas où tu veux venir avec ce post en fait -
    ++

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #16
    Membre Expert

    Homme Profil pro
    Chargé de Développement et d'Analyse de données
    Inscrit en
    Mars 2010
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chargé de Développement et d'Analyse de données
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 278
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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]
    ')
    Etienne ZINZINDOHOUE
    Billets-Articles

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    Cela revient à être la seule commande du lot, car chaque EXECUTE est lancé en dehors du contexte.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Utilisation Log4j dans les projets web
    Par RHmed dans le forum Développement Web en Java
    Réponses: 6
    Dernier message: 10/04/2013, 11h15
  2. Utiliser tilde dans les url
    Par SoulReaper dans le forum Apache
    Réponses: 4
    Dernier message: 10/02/2010, 19h07
  3. Réponses: 1
    Dernier message: 12/11/2009, 00h13
  4. Réponses: 9
    Dernier message: 05/11/2009, 18h14
  5. [Dojo] Utilisation signe < dans les "values" de la dojox.grid.cells.Select
    Par moukit233 dans le forum Bibliothèques & Frameworks
    Réponses: 2
    Dernier message: 16/09/2009, 10h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo