Discussion :

[Titonium]

Bonjour à tous,

ayant migré depuis peu sur SQL Server 2012, nous venons de constater un changement dans la manière d'évaluer les expression logiques dans la clause having.

J'ai crée une requête simplifiée qui permet de constater le problème :

Code :

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

1
2
select sum(0) 
having sum(0) >0  and 1/sum(0) >0

L'objectif est de tester la valeur d'une division. Evidemment, avant toute division, il est nécessaire de vérifier si la valeur du diviseur n'est pas égale à 0, c'est ce que je fais avec sum(0)>0. Sauf que la, il génère l'erreur suivante :

Msg 8134, Level 16, State 1, Line 1
Division par zéro.

SQL Server a donc évaluter toutes les expressions, malgré le fait que la première est fausse.
Dans notre précédente version d'SQL Server 2000, cela fonctionnait bien. D'autre part, un test similaire dans la clause WHERE ne génère pas d'erreur.

Le problème peut etre reproduit avec d'autre condition comme :

Code :

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

1
2
3
4
5
select 1, ISNUMERIC(num)
from (select '12J' as num) t
group by num
having ISNUMERIC((num))=1 
and max(cast(num as int)) >0

Ce qui génère :
Server: Msg 245, Level 16, State 1, Line 1
Échec de la conversion de la valeur varchar '12J' en type de données int.


Question : est-ce normal ? ya t-il un moyen de lui indiquer de ne pas évaluer les autres expressions si la première est fausse ?

Merci pour vos éclairages !

[rudib]

Hello,

apparemment l'optimiseur est capable de court-circuiter les prédicats, mais c'est sans garantie, donc il peut agir au coup par coup selon la requête, et tu ne peux pas baser ta logique sur ce comportement non prévisible.

à partir de 2012 tu peux utiliser TRY_CAST, pour ton deuxième exemple :

Code :

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

1
2
3
4
5
SELECT 1, ISNUMERIC(num)
FROM (SELECT '12J' AS num) t
GROUP BY num
HAVING ISNUMERIC((num))=1 
AND max(try_cast(num AS int)) >0

[Titonium]

Bonjour,

Merci pour ta réponse rapide, elle concorde avec une des hypothèses que nous avions.

Nous pensions aussi que cela pouvait être du aussi au parallélisme (il évalue toutes les expressions individuellement en même temps puis compilation des and/or)

Il n'y a donc pas de solution miracle, il faut réécrire les requêtes !

[aieeeuuuuu]

Bonjour,

En effet, l'optimiseur... optimise ! et pour cela, il vérifie les prédicats non par ordre d'écriture, mais de telle sorte que la vérification globale soit le plus rapide possible. Entre autres optimisations, il va donc commencer par ceux qui filtrent le plus selon ses propres estimations.


En revanche, les expressions d'un CASE sont évaluées dans leur ordre d'écriture, jusqu’à trouver la première qui soit vraie. Vous pouvez donc jouer là dessus si vous ne tenez pas à réécrire toutes vos requêtes :

Code :

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

1
2
3
4
5
6
7
8
 
SELECT sum(0) 
HAVING 1 = 
	CASE 
		WHEN sum(0) = 0 THEN 0
		WHEN 1/sum(0) > 0 THEN 1
		ELSE 0
	END