Reprise du message précédent :

par ce que ce n'est pas du tout le résultat qu'il cherche à avoir...

et que le limit ne peux pas s'appliquer à une sous-requête (ce qui donnerait le bon résultat)

attends, si tu limite ta requête à 1, en virant le distinct, chuis désolé mais ça donne le résultat qu'il a marqué en exemple!    
 
par contre, le problème est peut être mal posé!

si tu veux deux lignes, une pour chaque société, non

j'ai une question par rapport à tout ça, je l'ai exposé ici...
si vous pouvez m'éclairer...:
http://forum.hardware.fr/forum2.ph [...] subcat=395
c'est à peu pres la même chose (car je ne veux pas faire de calcul) mais je veux récupérer tous les champs de la ligne par rapport à un maxi (car dans cet exemple on a que 2 champs...)
concretement dans cet exemple:
societe    |   nom_collab   |   date    |   texte   |
-----------+----------------|-----------|-----------|
microsoft  |   billou       | 01/01/2002| gfdgd
microsoft  |   jobs         | 02/02/2002| gfdgfd
microsoft  |   bush         | 05/05/2002| tffgdf
wanadoo    |   saddam       | 02/02/2002| gfdgd
wanadoo    |   Mara's Dad   | 03/02/2002| gfdgd    
 
 
 
et j'aimerais  avoir pour chaque [société] le [nom_collab] de la derniere [Date]
 
 
societe    |   nom_collab   |   date    |   texte  |
-----------+----------------|-----------|----------|
microsoft  |   bush         | 05/05/2002| tffgdf   |
wanadoo    |   Mara's Dad   | 03/02/2002| gfdgd    |
 
coment fait on dans ce cas?

cherche de l'aide sur le mot-clé "having"

Ca sert à sélectionner les lignes qui doivent être envoyées au client. La différence avec la clause WHERE, c'est que le HAVING est effectué au dernier moment, alors que le SGBD cherche à effectuer le WHERE le plus tot possible.
L'inconvénient, c'est que c'est moins performant qu'un WHERE.
L'avantage, c'est qu'on peut l'utiliser pour n'importe qu'elle colonne du résultat, y compris une colonne calculée.
Par exemple :
 
SELECT equipe, count(*) as c
FROM employes
GROUP BY equipe
HAVING c > 10;
ne renverra que les équipes ayant plus de 10 employés. Mais on ne pas faire la sélection c > 10 dans le WHERE

dans mon cas, ça donnerait:
SELECT societe, nom_collab, date as D, texte
from ma_table
GROUP BY société
HAVING max(D)
 
ou bien une inversion entre le Group By et HAVING
après la question se pose pour savoir si:
HAVING MAX(...)
ça marche...
je vais tester demain, merci pour l'aide.
D'ailleur si il y a une autre solution, n'hésitez pas

 
Le HAVING est bel et bien après le GROUP BY.
 
Sinon, non, ta requête sera plutôt :
 
SELECT societe, nom_collab, date as D, texte  
from ma_table  
GROUP BY societe
HAVING max(date) = D
 
En effet, le HAVING marche comme une clause WHERE, il lui faut donc une condition, pas simplement une constante
 
En fait, comme l'a dit mrBebert, la requête :
 
SELECT societe, nom_collab, date as D, texte  
from ma_table  
GROUP BY societe
 
Va être effectuée, puis seuls les lignes ayant D = max(date) groupé par societe seront renvoyées. En fait, c'est un filtre de dernière minute qui se fait dans le jeu de résultat, et non dans les données elles-mêmes, d'où la baisse de perfs.

oui mais comme dit si bien mrBebert, la fonction HAVING sera effectuée en dernière, le server fait d'abord:
le GROUP BY societe
mais qu'est cequ'il en fait des champs non numérique? il ne peut pas agreger du texte ni des dates...
non? je me trompe sur toute la ligne?

   
 
Mais je comprends ce que tu entends par "champs non numérique"  
Tu sais bien quel est le format de chaque champ. Et ca ne varie pas d'une ligne à l'autre.

Euh...
J'ai confondu avec  
select A, sum(B) from.... group by A
alors je me suis dit qu'il y aurait une erreur si B etait de type Char par exemple...
il ne faut pas en tenir compte c'est moi qui délire tout seul dans mon coin