Discussion :

[Artemus24]

Salut à tous.

Impossible de déclarer une variable :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
use tempdb
 
Le contexte de la base de données a changé*; il est maintenant 'tempdb'.
 
declare @var as int
 
set @var = 10
 
Message 137, niveau 15, état 1, serveur ORION\SQLEXPRESS, ligne 1
La variable scalaire "@var" doit être déclarée.
select @var
 
Message 137, niveau 15, état 2, serveur ORION\SQLEXPRESS, ligne 1
La variable scalaire "@var" doit être déclarée.
 
Appuyez sur une touche pour continuer...

Je suis sous Microsoft SQL Server Express 2014.
Est-ce qu'il me manque une autorisation pour pourvoir faire une déclaration de variables ?
Si oui, où dois-je mettre cette permission ?

@+

[aieeeuuuuu]

Bonjour,

non, pas de privilèges nécessaires.

D'ailleurs la déclaration en elle même ne pose pas de problème ici, l'erreur se produit ensuite sur le SET.

je pense que cela vient de l'outil que tu utilises pour lancer les commandes qui doit découper en plusieurs batch...
Du coup, select @var n'est pas lancée dans la même session que la déclaration de la variable...

Comment lances-tu tes scripts ?

[Artemus24]

Salut aieeeuuuuu.

J'utilise le script batch windows pour lancer mes scripts Microsfot SQL Server :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@echo off
 
setlocal enableDelayedExpansion
 
chcp 1252 > nul
 
SET FIC=%~nx0
SET FIC=%FIC:bat=sql%
 
sqlcmd -S orion\SQLEXPRESS  -e  -E  -i %FIC%  -c ;
 
@echo.
pause
exit

Donc ce n'est pas une question de privilège à déclarer pour mon compte utilisateur.

J'ai pensé aussi que la version Express 2014 ne me permet pas de faire du procédurale (version limitée).

Quand le DECLARE est dans une procédure stockée ou une fonction, cela fonctionne parfaitement.
Avant de poster ce sujet, j'ai cherché à comprendre, mais je n'ai rien trouvé de probant.

Merci.
@+

[aieeeuuuuu]

non, c'est donc bien un problème de découpage de traitements.

Vous spécifiez le ";" :
-c ;.

L'exécution de votre script se fait donc dans des contextes différents pour chaque point-virgule présent.

Enlevez cette option lors de l'appel de sqlcmd, ou spécifiez GO comme séparateur pour retrouver un comportement proche de management studio

[Artemus24]

Salut aieeeuuuuu.

Non, cela n'a rien changé ! J'ai toujours le même problème.

Je te redonne le script batch windows, modifié comme tu me l'as demandé :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@echo off
 
setlocal enableDelayedExpansion
 
chcp 1252 > nul
 
SET FIC=%~nx0
SET FIC=%FIC:bat=sql%
 
sqlcmd -S orion\SQLEXPRESS  -e  -E  -i %FIC%
 
@echo.
pause
exit

Comme tu le constates, le point-virgule n'est plus interprété comme en tant que go.

Le script SQL server en remplaçant chaque ; par le go :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-- ==================
-- Lien vers Database
-- ==================
 
use tempdb
go
 
declare @var as int
go
set @var = 10
go
select @var
go
-- ===
-- Fin
-- ===
 
exit

Et le résultat de l'exécution :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
-- ==================
-- Lien vers Database
-- ==================
 
use tempdb
 
Le contexte de la base de données a changé*; il est maintenant 'tempdb'.
 
declare @var as int
 
set @var = 10
 
Message 137, niveau 15, état 1, serveur ORION\SQLEXPRESS, ligne 1
La variable scalaire "@var" doit être déclarée.
select @var
 
Message 137, niveau 15, état 2, serveur ORION\SQLEXPRESS, ligne 1
La variable scalaire "@var" doit être déclarée.
 
Appuyez sur une touche pour continuer...

@+

[aieeeuuuuu]

on s'est mal compris.

il faut que le DECLARE et le soit soient dans le même traitement.

il faut donc laisser les ; dans le script SQL.

Et comme séparateur de traitement pour sqlcmd, soit ne rien spécifier, soit spécifier GO.

Il est en effet parfois utile de séparer les traitements lorsqu'il faut par exemple créer une procédure au "milieu" d'un script (CREATE PROCEDURE doit être la première instruction du traitement).

[Artemus24]

Salut aieeeuuuuu.

J'ai supprimé quelques "go" dans mon exemple, mais cela ne fonctionne pas comme je l'aimerai :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- ==================
-- Lien vers Database
-- ==================
 
use tempdb
go
 
declare @var as int
set @var = 10
select @var
go
 
select @var
go
-- ===
-- Fin
-- ===
 
exit

Voici l'exécution :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
-- ==================
-- Lien vers Database
-- ==================
 
use tempdb
 
Le contexte de la base de données a changé*; il est maintenant 'tempdb'.
 
declare @var as int
set @var = 10
select @var
 
 
-----------
         10
 
(1 lignes affectées)
 
select @var
 
Message 137, niveau 15, état 2, serveur ORION\SQLEXPRESS, ligne 2
La variable scalaire "@var" doit être déclarée.
 
Appuyez sur une touche pour continuer...

Cette fois-ci, je n'ai plus aucune erreur, tant que je reste dans le premier lot (ce qui est avant le premier le "go".

Mais dès que je redemande un select, après le "go", je retrouve le même problème. La variable n'est plus connue !
C'est ce genre de comportement que j'ai du mal à comprendre : le traitement par lot.

Parfois le second lot ne peut fonctionner que si le premier lot a été validé.
Parfois il ne faut pas dissocier les lots comme je le fais, sinon cela ne fonctionne pas.

Pourrais-tu m'en dire plus ?

@+

[elsuket]

L'instruction GO, qui est liée SQLCMD et non pas à T-SQL, signale la fin du lot.
Donc pour toute instruction qui suit, les variables n'existent plus.

Vous devez donc les re-déclarer ou enlever le GO.

@++

[Artemus24]

Salut Elkuset.

Mais quel est l'utilité de ce "go" ?

J'ai l'impression que c'est une compatibilité ascendante avec une façon de faire qui n'a plus aucune raison d'être aujourd'hui.
J'ai un vague souvenir datant des années 70, où l'on gérait les lignes commandes de la même façon.
Il y avait une phase de saisie sur le terminal, puis ensuite l'envoi du lot vers l'unité central qui traitait alors ce lot.

Y-a-t-il un moyen de désactiver ce comportement ?

Ou de procéder autrement ? Ne pas passer pas le "sqlcmd".
Je désire travailler avec des batch windows. Y-a-t-il une autre façon de faire que d'utiliser "sqlcmd" ?

Merci.
@+

[aieeeuuuuu]

Comme l'a indiqué ElSuket, GO ne fait pas partie du T-SQL.

Donc, pour procéder autrement... il suffit de ne pas l'utiliser. Il n'est d'ailleurs pas indispensable, simplement parfois utile dans quelques cas :

1/ pouvoir insérer au milieu d'un script une instruction qui doit être la première d'un traitement, comme un CREATE PROCEDURE. Il suffit alors de faire précéder le CREATE d'un GO afin de séparer le script en plusieurs traitements.

2/ répéter plusieurs fois un traitement, en spécifiant GO n pour l'exécuter n fois. c'est parfois pratique lors de la constitution de jeu d'essai notamment.

3/ s'assurer du traitement d'un partie d'un script même en cas d'erreur sévère précedement. exemple :

Code :

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

1
2
3
4
5
 
select 1;
select 1/0;
GO
select 2;

Sans le GO, le SELECT 2 ne serait pas exécutè (arrêt du traitement sur la division par zéro).


4/ éviter des erreurs de parsing, par exemple après l'ajout d'une colonne :

Code :

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

1
2
3
4
 
alter table A add x int;
GO
select x from A

Sans le GO, une erreur de parsing sera générée, car au moment du parsing, la colonne x n'existe pas dans la table A

Mais à part pour le cas 2 un peu particulier, vous pouvez vous passer du GO et faire des scripts distincts.

[Artemus24]

Salut aieeeuuuuu.

En ce qui concerne mon exemple, j'ai compris que je positionnais mal le point-virgule, pardons le "go" dans le script.
Pour cet aspect là, le problème est résolu.

Après, pour gérer correctement le script, il faut savoir où le positionner.
Dans mes scripts, j'ai mis ce point-virgule après chaque pavé correspondant à un objet dans SQL Server.
Genre : base de données, table, trigger, procédure stockées ...

Je pense qu'à l'usage, je vais me familiariser avec cette façon archaïque de travailler.

La question que j'ai posé à Elsuket est de savoir s'il existe un utilitaire similaire à SQLCMD, sans avoir à gérer ce "go" ?
Vu qu'il n'y a pas eu de réaction, je pense que la réponse est non.

Vous dites que l'on peut s'en passer, peut-être, mais pas en totalité car sans ce "go", rien se sera envoyer vers SQL Server.

Je clôture le sujet.

Merci à tous.
@+

[SQLpro]

Salut aieeeuuuuu.

En ce qui concerne mon exemple, j'ai compris que je positionnais mal le point-virgule, pardons le "go" dans le script.
Pour cet aspect là, le problème est résolu.

Après, pour gérer correctement le script, il faut savoir où le positionner.
Dans mes scripts, j'ai mis ce point-virgule après chaque pavé correspondant à un objet dans SQL Server.
Genre : base de données, table, trigger, procédure stockées ...

Je pense qu'à l'usage, je vais me familiariser avec cette façon archaïque de travailler.

La question que j'ai posé à Elsuket est de savoir s'il existe un utilitaire similaire à SQLCMD, sans avoir à gérer ce "go" ?
Vu qu'il n'y a pas eu de réaction, je pense que la réponse est non.

Vous dites que l'on peut s'en passer, peut-être, mais pas en totalité car sans ce "go", rien se sera envoyer vers SQL Server.

Je clôture le sujet.

Merci à tous.
@+

Voici mon mémento pour cette partie :


Il ne faut donc jamais placer un GO dans :

• une routine SQL (Procédure, UDF, déclencheur)
• Un batch

En revanche, le GO étant un séparateur de batch vous pouvez envoyer un ensemble de batch séquentiels située dans un seul et même fichier, à condition de séparer chacun de vos batch par un GO.

le point virgule est un séparateur d'instruction SQL. Rien à voir avec le GO et il est interprété par le moteur SQL.

Il n'y a rien d'archaïque là dedans, c'est vous qui interprétez mal les choses, vu que vous ne connaissez que certains SGBDR et donc avez une vue biaisé par les habitudes acquises par MySQmerde et DB2
Ce concept de séparateur de lot existe dans d'autres SGBDR !

• \ dans oracle
• à définir dans Interbase/Firebird (avec la commande SET TERM)
• à définir avec MySQmerde (commande delimiter - visiblement vous ne connaissiez pas la chose !!!!)
• à définir avec DB2 (commande t – dans la ligne de commande)

L'intérêt du GO est qu(il a un paramètre de nombre de fois (à défaut 1).
par exemple pour peupler une table rapidement avec des valeurs par défaut :

Code :

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

1
2
3
4
5
6
7
8
 
CREATE TABLE T_CALENDRIER_CLD
(CLD_DATE DATE PRIMARY KEY)
GO --> une seule fois !
 
INSERT INTO T_CALENDRIER_CLD
SELECT DATEADD(day, 1, COALESCE(((SELECT MAX(CLD_DATE) FROM T_CALENDRIER_CLD)), '1999-12-31'))
GO 10 --> 10 fois

Enfin, il est parfois nécessaire pour que l'optimiseur puisse faire son boulot. Exemple :

Code :

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

1
2
3
4
5
6
CREATE VIEW V_GET_JOUR_HEURE
AS
SELECT CAST(GETDATE() AS DATE) AS JOUR, 
       CAST(GETDATE() AS TIME(0)) AS HEURE;
 
SELECT * FROM V_GET_JOUR_HEURE;

Cette commande va générer une erreur car la vue n'est pas conçue au moment ou l'analyse de la requête a lieu...

Avec un GO, tout rendre dans l'ordre :

Code :

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

1
2
3
4
5
6
7
CREATE VIEW V_GET_JOUR_HEURE
AS
SELECT CAST(GETDATE() AS DATE) AS JOUR, 
       CAST(GETDATE() AS TIME(0)) AS HEURE;
GO
 
SELECT * FROM V_GET_JOUR_HEURE;

Enfin, si vous aviez cherché un peu c'était indiqué dans mon tuto :
http://sqlpro.developpez.com/cours/s...nsactsql/#L2.7

A +

[Artemus24]

Salut SQMPRO.

Il n'y a rien d'archaïque là dedans, c'est vous qui interprétez mal les choses, ...

Vous avez tort.
Le concept de traitement par lot vient du mainframe qui ne savait pas faire de l'interactif.
Pourquoi ? Tout est mis en commun et tout est centralisé sous un seul compte.
De ce fait, lancer un traitement, nécessite de le sérialiser dans la seule et unique fil d'attente des traitements.
Ceci se nomme un batch et c'est la façon normal de fonctionner sous IBM MVS TSO ISPF.
Toute personne ayant fait du gros système sait cela !

Je suppose que SQLServer a été créé sur ce genre de machine, et pour des raisons historiques, à conserver un compatibilité ascendante.
Sur des micros ordinateurs, cette façon de faire de travailler n'a plus aucune raison d'être aujourd'hui.

... vu que vous ne connaissez que certains SGBDR et donc avez une vue biaisé par les habitudes acquises par MySQmerde et DB2

Vous dites n'importe quoi !
Je connais sous gros système ibm : dl1, idms, db2, qbe, ims, focus, natural adabase, socrate, data warehouse.
Sous gros système bull : ids II
Sous micro windows : mysql, firebird et maintenant un peu SQL Server.
Sous unix : informix mais là, j'ai pratiquement tout oublié.

Ce concept de séparateur de lot existe dans d'autres SGBDR !

C'est faux ! C'est vous qui faites la confusion.

La commande delimiter que je connais n'a rien à voir avec le traitement par lot.
C'est juste une façon de modifier le séparateur d'instruction dans un script afin qu'il ne soit pas interprété comme marque de fin de ligne.
Rien à voir avec un traitement par lot où l'on peut répéter plusieurs fois le même bloc d'instruction.

On se sert de ce delimiter dans la création des procédures stockées sous mysql et firebird.
Sous DB2 z/os cette notion n'existe pas, car tout ce fait dans du JCL (le batch gros système sous IBM).
Pourquoi ? Car DB2 z/os se traite et s'exécute qu'avec du JCL, ce que vous ignorez !!!

Encore une fois, vous faites la confusion entre DB2 z/os que vous ne connaissez pas !
IBM DB2 est trop flou car il existe une version DB2 sous AS/400.
Et il y a DB2 LUW sous linux, ainsi que sous windows (ce que vous connaissez) et enfin sous MAC os/x.
Je ne connais pas ces autres version DB2. J'étais administrateur DB2 sous IBM z/os.
Escartefigue confirmera mes propos au sujet des différentes versions de DB2.

En résumé, ce "go" est une grosse merde qui n'a plus aucune raison d'être, sauf à compliquer à outrance les traitements.

@+

[aieeeuuuuu]

En résumé, ce "go" est une grosse merde qui n'a plus aucune raison d'être, sauf à compliquer à outrance les traitements

Que n'avez-vous pas compris dans mon post #10 pour dire cela ?

Il ne complique les traitements que si on l'utilise mal, mais ça c'est le cas de toutes les instructions de tous les langages !