ça n'a rien à voir avec la version de Mysql, on l'a souligné tout à l'heure, l'erreur provient du fait que les champs négociés au niveau du HAVING doivent faire partie de l'agrégat GROUP BY ou du SELECT.

La preuve, pour résoudre le problème autrement on pourrait mettre la condition (nbPlaces >0 OR `g`.maxUser IS NULL) dans un WHERE sans solliciter le HAVING.

Le WHERE, contrairement au HAVING, a une vision globale des champs des tables sources ouvertes par le FROM et ne se contente pas des champs cités par le SELECT.

Si un WHERE il y'a le jeu de données sources est filtré à l'ouverture des tables sources selon les critères définis

Si un GROUP BY il y'a le HAVING filre les enregistrements groupés selon les critères de regroupement.

Le fltrage having s'effectue alors après le regroupement et doit utiliser alors les champs existant dans la clause GROUP BY ou à défaut SELECT

Globalement, la règle conceptuelle dit que seuls dépondent du select non pas dans l'ordre mais dans la pésence, les champs du regroupement qui ne doivent pas référencer un champ calculé. La condition having dépond des champs du Group By.

La séquence d'exécution d'une requête SELECT est :
1. Ouverture des sources et filtrage du jeu de données utiles : FROM et WHERE (éventuelment ORDER BY aussi pour appliquer un tri)

2. Construction du tuple selon la structure du SELECT

3. Regroupement (GROUP BY) +/- filtrage du regroupement (HAVING)

[quote="Moosh"]5.0.2 <- je suppose que tu parles de la version de Mysql[/quote]

Oui. Pour la suite:
http://forums.mysql.com/read.php?10,48055,48055#msg-48055

Merci Ripat, j'allais donner ma réponse finale mais tu es encore plus complet.


5.0.2 <- je suppose que tu parles de la version de Mysql

[color=darkblue]est -ce que c'est MySQL ?[/color]

Intéressant.

[quote="Hash Air"]En théorie, les champs qui apparaissent dans la clause HAVING doivent provenir du SELECT.[/quote]

Oui et non. Apparemment, tout dépend de la version.

Un peu de théorie donc (tirée de la [url=http://dev.mysql.com/doc/mysql/en/select.html]doc[/url] - en anglais car, une fois encore, la doc en français est curieusement muette sur le sujet):
[list=1]
[*]Avant 5.0.2 les colonnes du HAVING doivent faire référence aux colonnes définies dans un des groupes suivant:
[list]
[*]SELECT
[*]des fonctions de groupement (Aggregate Functions)
[*]subqueries[/list]

[code]SELECT COUNT(*) FROM table GROUP BY col1 HAVING col1 = 2; # retourne une erreur
SELECT COUNT(*), col1 FROM table GROUP BY col1 HAVING col1 = 2; # correct[/code]

[*]Après 5.0.2 les colonnes du HAVING doivent faire référence aux colonnes définies dans un des groupes suivant:
[list]
[*]SELECT
[*]des fonctions de groupement (Aggregate Functions)
[*]subqueries
[*]GROUP BY[/list]

[code]SELECT COUNT(*) FROM table GROUP BY col1 HAVING col1 = 2; # requête correcte[/code]

[*]Et, pour info, en SQL standard:
[list]
[*]des fonctions de groupement (Aggregate Functions)
[*]GROUP BY[/list][/list]

Ca, c'est la théorie. En pratique, d'après ce qui précède, dans MySQL 4.1 une requête comme :
[code]SELECT COUNT(col1) FROM table GROUP BY col1 HAVING col1 = 2;[/code]
devrait marcher puisque référence est faite à la fonction de groupement COUNT(). Et bien, non, ça ne marche pas. Donc il y aurait peut-être bien un bug ou, à tout le moins, une imprécision dans la doc. Je poste ceci sur le forum de MySQL AB et je posterai ici la réponse.

En théorie, les champs qui apparaissent dans la clause HAVING doivent provenir du SELECT. Puisqu'il n'y est pas dans le premier exemple je pense que MySQL le remplace par NULL et la clause "NULL IS NULL" annule l'effet de ton HAVING. Réessaie le premier exemple en citant explicitement ton champs maxUser dans le SELECT pour voir.

Un truc intéressant: si tu n'avais pas de référence au COUNT() dans ton HAVING, MySQL l'aurait certainement fusionné à la clause WHERE et on n'en aurait jamais parlé. :D

Petit mystère, mais il y a un détail qui me surprend: j'ai toujours eu des problèmes en préfixant les champs tout en protégeant les noms, ainsi, si je fait `g`.`id`, ça va planter, mais avec g.id ça va fonctionner: Donc la première requête revue comme ceci devrait fonctionner ?
[code]SELECT g.id AS gid, g.maxUser - count(ug.user) AS nbPlaces
FROM `groups` AS g
LEFT JOIN `rel_group_user` AS ug
ON g.id = ug.team
GROUP BY (g.id)
HAVING nbPlaces > 0 OR g.maxUser IS NULL
ORDER BY nbPlaces DESC[/code]
:?: Sinon, quel est le message d'erreur ?

SELECT g.id AS gid,
              g.maxUser - count(ug.user) AS  nbPlaces
             FROM `groups` AS  g                            
             LEFT JOIN  `rel_group_user` ug
             ON    `g`.`id` = `ug`.`team`
             GROUP BY (`g`.`id`)
             HAVING nbPlaces > 0 OR g.maxUser IS NULL 
             ORDER BY nbPlaces DESC

SELECT g.id AS gid, 
              g.maxUser - count(ug.user) AS  nbPlaces,
              g.maxUser g_maxUsers
             FROM `groups` AS  g                            
             LEFT JOIN  `rel_group_user` ug
             ON    `g`.`id` = `ug`.`team`
             GROUP BY (`g`.`id`)
             HAVING nbPlaces > 0 OR g_maxUsers IS NULL 
             ORDER BY nbPlaces DESC

Salut

Qui va me donner l'explication parfaite

voici une requete sql qui foire

[php]
SELECT g.id AS gid,
g.maxUser - count(ug.user) AS nbPlaces
FROM `groups` AS g
LEFT JOIN `rel_group_user` ug
ON `g`.`id` = `ug`.`team`
GROUP BY (`g`.`id`)
HAVING nbPlaces > 0 OR g.maxUser IS NULL
ORDER BY nbPlaces DESC
[/php]

voici la requete corrigée

[php]
SELECT g.id AS gid,
g.maxUser - count(ug.user) AS nbPlaces,
g.maxUser g_maxUsers
FROM `groups` AS g
LEFT JOIN `rel_group_user` ug
ON `g`.`id` = `ug`.`team`
GROUP BY (`g`.`id`)
HAVING nbPlaces > 0 OR g_maxUsers IS NULL
ORDER BY nbPlaces DESC
[/php]

Qui peut expliquer pourquoi il faut ajouter
g.maxUsers dans la liste des champs du select alors qu'il vient de la table FROM (donc le champs est toujours là pour tous les rows