Discussion :

[soazig]

Bonjour,
Je souhaite comprendre ce que fait cet appel incorrect à une procédure stockée

Code :

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

1
2
3
 
EXECUTE  [dbo].[UPD_ASF_FORECASTS_CONTREPARTIE]    @pIn_process_id  ,@pIn_Upload_Number  ,pIn_Year
					,@pInScenario_min,@pInScenario_max, @vRepartition_niveau  ,@vRepartition_etape

Alors que l'appel correct est celui là.

Code :

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

1
2
3
EXECUTE  [dbo].[UPD_ASF_FORECASTS_CONTREPARTIE]    @pIn_process_id  ,@pIn_Upload_Number  ,@pIn_Year
					,@pInScenario_min,@pInScenario_max, @vRepartition_niveau  ,@vRepartition_etape

La différence entre les deux est l'oubli dans @ avant un nom de variable dans l'appel incorrect
Voilà le Prototype de la fonction appelée

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
 
create PROCEDURE [dbo].[UPD_ASF_FORECASTS_CONTREPARTIE] 
	@pIn_process_id int,
	@pIn_Upload_Number nvarchar(20),
	@pIn_Year nvarchar(4),	
	@pInScenario_min int,
	@pInScenario_max int,
 
	@pIN_repartition_niveau char(1) , 
	@pIN_repartition_etape nvarchar(10)  
AS
BEGIN
-- INSERT ...
--SELECT..
		WHERE 
			FR.Year=@pIn_Year
 
END

J'ai cherché longtemps pourquoi je n'avais pas de données insérées alors que j'aurai dû.
Pourquoi l'appel incorrect passe t-il à la compilation de la procédure stockée, et comment se comporte-t-il?
[edit]Version de SQL Server 2005[/edit]
A+
Soazig

[soazig]

ReBonjour,
Je viens de faire l'essai suivant

Code :

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

1
2
3
4
5
6
7
8
9
create PROCEDURE [dbo].[ESSAI] 
	@pIn_Year  nvarchar(4)
as
begin
	Select @pIn_Year
end
 
declare pIn_Year nvarchar(4)
exec [ESSAI] pIn_Year

Et j'obtiens

pIn_

(1*ligne(s) affectée(s))

On dirait qu'il me transforme pIn_Year en 'pIn_Year'.
Mais je préférerais grandement qu'il m'envoie un message d'erreur pour que je rajoute les quotes.

Si vous avez des explications, des ruses, l'option d'installation qu'il faut cocher pour que sQL server soit moins permissif , j'accepte toutes les remarques.
A+
soazig

[mikedavem]

Bonsoir,

En TSQL les variables sont précédées d'un @

Pourquoi voulez vous aller contre ça ?

Il est normal que vous ayez une erreur

Un code qui fonctionnerait serait le suivant :

Code :

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

1
2
3
declare @pIn_Year nvarchar(4)
SET @pInYear = 'valeur'
exec ESSAI @pIn_Year

++

[soazig]

Je suis d'accord qu'en TSQL les variables sont précédées d'un @
Mais le problème c'est que je n'ai pas d'erreur. Dans le cas réel, j'avais 10 procédures stockées qui s'appelaient les une les autres, et à un moment, j'ai oublié le @, toutes mes procédures stockées, se compilaient, s'exécutaient, sauf que bien évidemment la valeur de la variable @pIn_Year n'est pas 'pIn_Year', et donc je n'obtenais pas le résultat souhaité.

Ma question est donc pourquoi je n'ai eu aucun message d'erreur. Y a-til une option pour rendre SQL server moins permissif? du genre option Explicit de VB ou Option Strict on pour VB.NET.

J'espère qu'une telle option existe, car je me connais, il est possible que j'oublie à nouveau ce sacré @. En général ce genre d'étourderie ne passe pas à la compil.
A+
soazig

[cmako]

Ma question est donc pourquoi je n'ai eu aucun message d'erreur. Y a-til une option pour rendre SQL server moins permissif? du genre option Explicit de VB ou Option Strict on pour VB.NET.

J'espère qu'une telle option existe, car je me connais, il est possible que j'oublie à nouveau ce sacré @. En général ce genre d'étourderie ne passe pas à la compil.
A+

Non, ça n'existe pas.
De toute façon il y a plein d'aberrations dans SQL Server.
Bienvenu au club.

[elsuket]

De toute façon il y a plein d'aberrations dans SQL Server.

Excepté celle que décrit soazig, dont je doute fortement, citez-nous les autres.
(Non je ne travaille pas pour MS : quand un produit est bon, je le dis; quand c'est un produit médiocre, je le dis aussi).

[agemis31]

Bonsoir,

On trouve toujours quelques aberrations dans tout produit, reste que SQL serveur me semble plutôt cohérent par rapport à la concurrence.
Je confirme qu'elsuket ne travaille pas pour ms

@+

[mikedavem]

Bon je ne travaille pas non plus pour microsoft mais quand même.

Il suffit simplement de savoir qu'au moment de la création d'une procédure stockée il n'ya simplement qu'une vérification syntaxique qui est effectuée pour pouvoir par exemple faire de la résolution de noms différés (faire référence donc à des objets encore inexistants)

La compilation ne se fait qu'à la première exécution de la procédure stockée.
Ceci n'est donc pas une abbération en soi

PS pour agemis31 :

agemis31 dit : elsuket est honnête et ne travaille pas pour microsoft
elsuket dit : Nous sommes de 2 catégories opposés
Qui est honnête ?

++

[agemis31]

mikedavem, tu as tout à fait raison pour la compilation différée.

Pour la devinette, en raisonnant relationnel, on va dire qu'il n'y a pas d'ordre de parole.
Je crois qu'elsuket l'a joué fûté, moins de prise de position, donc moins de risque. Il n'y a pas de morale :-)

Code :

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

1
2
3
DECLARE @t TABLE (pseudo varchar(20), bhonnete bit)
INSERT INTO @t (pseudo, bhonnete) VALUES (agemis31, 0), (elsuket, 0)
INSERT INTO @t (pseudo, bhonnete) VALUES (agemis31, 0), (elsuket, 1)

@+

[soazig]

Rebonjour,
Eh, je n'avais pas lancé un troll au départ.
Avez-vous une réponse constructive, genre "Set Machin on" à spécifier

A+
Soazig

[elsuket]

Bonjour Soazig,

Nous sommes désolés, mais nous n'avons pas de réponse à ton problème.
Aucune option ne permet de rentre optionnel l'arobase qui doit se trouver devant tout variable.

pIn_Year aurait pu être un curseur, mais @pIn_Year n'est pas de ce type ...

@++

[soazig]

Rebonjour;
Je ne voulais pas rendre optionnel le @ mais avoir une erreur à l'execution ou à la compilation quand je l'oublie par mégarde, c'est différent.
A+
Soazig

[mikedavem]

Bonsoir soazig,

comme je l'ai expliqué un peu plus haut, lorsque vous créez une procédure stockée via la commande CREATE PROCEDURE .... il n'y a qu'une vérification syntaxique qui se fait.

La compilation de la procédure ne s'effectue qu'à la première exécution de celle-ci (EXEC procedure).

Il est normal qu'au début que SQL Server ne vous donne pas d'erreur.

++

[soazig]

Oui mais à aucune exécution je n'ai eu une erreur (toutes les executions y compris la première se sont bien passée)
Il me semblait bien que la compilation ne se fait qu'à la première exécution, mais dans l'exemple que je cite dans mon premier post, je n'ai obtenu aucune erreur, ni à la compilation ni aux 5 exécutions suivantes, qu'il m'a fallu pour comprendre pourquoi le résultat obtenu n'était pas le bon.


Soazig

[elsuket]

il n'y a qu'une vérification syntaxique qui se fait.

Ha ben si, en revanche

l n'ya simplement qu'une vérification syntaxique qui est effectuée pour pouvoir par exemple faire de la résolution de noms différés (faire référence donc à des objets encore inexistants)

Cela est vrai et un peu déroutant ...

Code :

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

1
2
3
4
5
6
7
CREATE PROCEDURE spTest
	toto INT
AS
BEGIN
	SELECT 1
END
GO

Retourne :

Msg*102, Niveau*15, État*1, Procédure*spTest, Ligne*2
Syntaxe incorrecte vers 'toto'.

De même :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE PROCEDURE spTest
	@toto INT
AS
BEGIN
	SELECT @toto
END
GO
 
EXEC dbo.spTest toto = 2

retourne :

Msg*102, Niveau*15, État*1, Ligne*1
Syntaxe incorrecte vers '='.

Dans le cas de soazig le parsing de la procédure a correctement fonctionné, c'est l'appel qui n'aurait pas du fonctionner, et je ne vois aucune raison ni option pour que cela ait fonctionné.
A tout hasard, sous quelle version et service pack avez-vous pu effectuer cet appel ?

@++

[agemis31]

Bonjour,

soazig, tu devrais peut être voter pour cette demande de fonctionnalité.

Sinon, quand tu dis:

Je viens de faire l'essai suivant

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE PROCEDURE [dbo].[ESSAI] 
	@pIn_Year  nvarchar(4)
AS
begin
	SELECT @pIn_Year
end
 
 
declare pIn_Year nvarchar(4)
exec [ESSAI] pIn_Year

Et j'obtiens
Citation:
pIn_

(1*ligne(s) affectée(s))


On dirait qu'il me transforme pIn_Year en 'pIn_Year'.

Je ne comprends par que la ligne declare pIn_Year nvarchar(4) puisse passer.

Pour le reste c'est effectivement une conversion implicite de pIn_Year en 'pIn_Year' puisque pIn_Year n'est pas une variable et que le paramètre @pIn_Year de la procédure est une chaîne.
Cette conversion est sans doute génante ici et pratique ailleurs, et ce serait bien, en effet, d'avoir un peu plus de contrôle sur ce comportement.

@+

[mikedavem]

Oui mais à aucune exécution je n'ai eu une erreur (toutes les executions y compris la première se sont bien passée)
Il me semblait bien que la compilation ne se fait qu'à la première exécution, mais dans l'exemple que je cite dans mon premier post, je n'ai obtenu aucune erreur, ni à la compilation ni aux 5 exécutions suivantes, qu'il m'a fallu pour comprendre pourquoi le résultat obtenu n'était pas le bon.


Soazig

Si je reprends votre 1er exemple soazig :

Dans ta 1ère fonction la variable @pIn_Year est de type nvarchar.

L'appel de ta procédure dans votre cas est correct.

Code :

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

1
2
3
EXECUTE  [dbo].[UPD_ASF_FORECASTS_CONTREPARTIE]    @pIn_process_id  ,@pIn_Upload_Number  ,pIn_Year
					,@pInScenario_min,@pInScenario_max, @vRepartition_niveau  ,@vRepartition_etape

La conversion de pIn_Year est implicite et celle-ci correspond bien à ta variable @pIn_Year de ta fonction. Vous n'aurez donc jamais d'erreur dans ce cas.

Par contre effectivement je suis d'accord avec agemis31, peut être qu'un meilleur contrôle à ce niveau pourrait être une bonne idée d'amélioration.

++

[SQLpro]

A noter : cela ne se produit que si la chaine de caractères passée en argument ne comporte pas de caractères spécifique autre que ceux prévue pour un nom (par exemple pas de blanc.

En effet

exec [ESSAI] pIn_Year

Coorespond à :

Code :

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

exec [ESSAI] 'pIn_Year'

A +

[cmako]

Bonsoir,

On trouve toujours quelques aberrations dans tout produit, reste que SQL serveur me semble plutôt cohérent par rapport à la concurrence.
Je confirme qu'elsuket ne travaille pas pour ms

@+

Depuis que je travaille avec SQL Server, je ne vois que ça : Des aberrations.

Voici une petite liste :
- curseurs trop lents et peu performants
- pas de typage relatif (%TYPE en Oracle)
- triggers limités
- pas de transactions autonomes
- pb déclarations d'UDF


Le client a choisi SQL Server par choix budgétaire. Je le respecte (le client), mais je pleure derrière.

[soazig]

Bonjour,
Si j'ai bien compris les derniers échanges, il est recommandé de ne pas être une tête de linottes qui oublie les @, car sinon gare au débogage.


Voici quelques précisions qui m'ont été demandées
D'abord la version donné par les requêtes suivantes :

Code :

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

1
2
3
4
5
SELECT SERVERPROPERTY('ProductLevel') as product_level
 
SELECT @@VERSION as version
 
SELECT SERVERPROPERTY('ProductVersion') as ProductVersion

product_level
SP3

(1*ligne(s) affectée(s))

version
Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)
Nov 24 2008 13:01:59
Copyright (c) 1988-2005 Microsoft Corporation
Developer Edition on Windows NT 5.2 (Build 3790: Service Pack 2)


(1*ligne(s) affectée(s))

ProductVersion
9.00.4035.00

(1*ligne(s) affectée(s))

Ensuite, voilà un bout de script pour reproduire le problème

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
25
26
27
28
29
30
if exists (select null from information_schema.routines where routine_name  ='ESSAI')
drop procedure  [dbo].[ESSAI] ;
 
GO
if exists (select null from information_schema.routines where routine_name  ='ESSAI_APPELANT')
drop procedure [ESSAI_APPELANT];
GO
CREATE PROCEDURE [dbo].[ESSAI] 
	@pIn_Year  nvarchar(4)
AS
begin
	SELECT @pIn_Year as mon_param
end
GO
Create procedure [dbo].[ESSAI_APPELANT]
As 
begin
--declare @pIn_Year nvarchar(4)
	exec [ESSAI] pIn_Year
end 
GO 
exec  [dbo].[ESSAI_APPELANT]
 
if exists (select null from information_schema.routines where routine_name  ='ESSAI')
drop procedure  [dbo].[ESSAI] ;
 
GO
if exists (select null from information_schema.routines where routine_name  ='ESSAI_APPELANT')
drop procedure [ESSAI_APPELANT];
GO

Et le résultat obtenu

mon_param
pIn_

(1*ligne(s) affectée(s))

Et le résultat souhaité,
une erreur soit lors de la création de ESSAI_APPELANT soit lors de l'execution de ESSAI_APPELANT.


Cordialement
Soazig