Bonjour à tous,
 
Je m'excuse d'avance pour le dérangement si ma question est conne, mais j'ai une requête SQL à faire passer dans phpmyadmin pour l'administration d'un forum, requête qui est la suivante :
 

 
Et je me fais jeter, apparemment au niveau du SELECT MIN(...
 
Voilà le code de l'erreur :

 
Je n'ai pas bien compris le rôle de la virgule entre les 2 SELECTS, peut être que vous saurez éclairer ma lanterne, en tout cas merci d'avance!

Mon dieu pourtant je googlise tout ce que je peux, ça a l'air limite exotique comme instruction... Pitié, j'offre ma soeur à qui m'aidera

dis-nous ce que tu veux faire, ça sera plus simple

 
Il s'agit d'une modification "modifiée" ( ) visant à améliorer la présentation des smilies sur un forum phpbb. Le code complet SQL qui m'a été gentillement procuré est le suivant :
 

 
La première partie du code ne pose aucun problème et ajoute simplement des champs à certains trucs et des tables. Le problème se situe donc à l'avant-avant dernière instruction, qui elle ne passe pas, visiblement pour un problème de syntaxe.
Cela pourrait être lié à un problème de version, le code qu'on m'a procuré étant relativement vieux.

Bonjour,dans l'instruction WHERE s2.emoticon = s.emoticon,essaie de remplacer la dernière partie par  's.emoticon',
dis moi le resultat
Bye

la ligne 41 , il manque pas une condition ?

 
Merci beaucoup pour ton attention.
 
J'ai fait ce que tu m'as conseillé, le message d'erreur a légèrement changé du coup :
 

 
EDIT: Autant pour moi, y'a rien qu'a changé

petit up  

meat > Avant de balancer ta requete INSERT, essaie de voir ce que ça donne juste avec le SELECT dans l'interpréteur de requête MySQL.

Essaye
 
INSERT INTO `phpbb_smilies_tmp` SELECT s.smilies_id AS id, (SELECT MIN(smilies_id) FROM `phpbb_smilies` s2 WHERE s2.emoticon = s.emoticon) AS key    FROM `phpbb_smilies` s;
 
Pas sur que ce soit ça mais sinon je vois pas...

 
Le SELECT seul me renvoie pile la même erreur.

 
Ca me donne la même erreur, le "MIN(" s'affiche en rouge dans le résumé de la requête, et il affiche ça :
 

 
Ce qui après vérification est la même erreur

 
J'ai retenté juste à partir du 2ème SELECT, et il me jette avec l'erreur suivante :  
 

Sinon, j'ai retrouvé un vieux thread où des gens ont le même problème, avec le même code ou presque, mais l'alphabet utilisé (du cyrillique ? ) me fait dire que ça va être coton de comprendre ce qu'ils disent...
 
http://www.phpbbguru.net/community/topic9893.html

on peut voir une tof de la soeur ?

 
La tof après la solution    
 
On lui a dit plusieurs fois qu'elle ressemble à Emmanuelle Béart...

 
SELECT s.smilies_id, (SELECT MIN(smilies_id)  
                            FROM `phpbb_smilies` s2  
                            WHERE s2.emoticon = s.emoticon)    
FROM `phpbb_smilies` s;
 
le problème qu'il y a avec cette requête c'est que dans "MIN(smilies_id)" il sait pas ou il doit allé chercher le "smilies_id" (soit dans 's' soit dans 's2') d'où ton erreur
 
SELECT s.smilies_id, (SELECT MIN(s2.smilies_id)  
                            FROM `phpbb_smilies` s2  
                            WHERE s2.emoticon = s.emoticon)    
FROM `phpbb_smilies` s;
 
a mon avis ça devrait solutionné ton problème. D'ailleur je ne comprends pas comment ça se fait que personne d'autre l'ai remarqué avant moi.
 
EDIT: si ça marche, je veux ta soeur

Merci pour ton aide, mais j'crois que pour l'instant ma soeur reste libre :whistle
 
En fait il me balance la même erreur, toujours pareil... A croire que c'est le smilies_id qui déconne, genre ça s'apelle plus comme ça, ou c'est un type de variable dont on peut pas prendre le min()...
 
J'crois que je vais abandonner

bon avant d'abandonner teste ceci:
 
SELECT s2.smilies_id
FROM `phpbb_smilies` s2  
 
et
 
SELECT MIN(s2.smilies_id)  
FROM `phpbb_smilies` s2  
 
dit moi si ça te renvoit quelque chose
teste aussi ceci
sinon tu peux également nous donné la structure de la table phpbb_smilies avec le nom des champs et le type de chacun de ceux-ci...
Après ça on pourra surement t'en dire plus.
 

Le mec qui m'a fourni le code me dit qu'il faut que j'update ma version de MySQL pour qu'elle soit au moins en 4.X ou 5.X... Je viens d'acheter mon hébergement chez OVH, c'est quoi la version qu'ils m'ont mis ?
 
Ca va peut être vous aider à traduire la requête, non ? Merci d'avance et pour tout
 
EDIT : J'ai la version 4.0.25 de MySQL, ça me paraît un peu gros un tel problème de compatibilité...

 
La première requête que tu dis me renvoie une liste, avec en en-tête ça :
Affichage des enregistrements 0 - 29 (212 total, traitement: 0.0434 sec.)
 
La seconde, me renvoie ça :  
Affichage des enregistrements 0 - 0 (1 total, traitement: 0.0004 sec.)
Avec une liste beaucoup plus courte, puisqu'elle ne compte qu'une seule entrée.
 
Tu veux plus de détails ?  

Ma table phpbb_smilies compte les entrées suivantes :
 
smilies_id (smallint(5)), code (varchar), smilie_url (varchar), emoticon (varchar), smilies_order (int(5)), smile_group (smallint(5)) et sort_key (smallint(5))
 
Concernant la table phpbb_smilies_tmp, j'ai que les entrées suivantes :
 
id (smallint(5)), key (smallint(5))
 
La table tmp est créée par les premières commandes et ne comporte en principe que ces entrées, là je pense que c'est normal

Chez OVH tu n'as pas le droit aux select imbriquée, car la version de MySQL est trop ancienne
Bon voilà tu as eu ta réponse : c'est po possible payes ta soeur maintenant

 
Mais j'ai aucun moyen de réaliser cette requête alors ?
genre en deux temps, je sais pas moi...
 
Ah pas de solution, pas de soeur
 
Apparemment c'est faisable en passant par une table temporaire, ou alors en utilisant l'instruction JOIN...

Sur cette page, il y'a un exemple intéressant... Mais je crains de faire une connerie en adaptant mon code  
 
Si un habitué du SQL passe par là, ça devrait n'être qu'une simple formalité pour lui, au vu de l'exemple :  
 
    *  Avec des tables temporaires.
 
Pour les requêtes plus complexes, on crée une table temporaire où on insère les enregistrements qu'aurait normalement contenus la sous-requête. Puis on fait une jointure entre la table temporaire et la table d'origine.
 
Ex : pour chaque valeur de champ2, on veut le maximum de champ1 dans la table.

 
Devient :
 

pas mal le coup des 20 posts pour se rendre compte que la version de MySQL ne supportait pas les requetes imbriquees (4.1.9 et plus)
 
il y a toujours un moyen de s en sortir sans requetes imbriquees
peux tu reexpliquer precisement le but de ta manoeuvre (avec un petit exemple stp ?)

 
Et bien je suis pas encore capable de t'expliquer clairement ce que mon code fait, vu que je n'ai pas de grandes connaissances de MySQL (d'où le coup des 20 posts, au cours desquels tu auras remarqué que j'avançais petit à petit dans mon problème, après une multitude de mails et/ou googlisations effectuées).
 
Ce code m'a été fourni par une tierce personne, et ce qui déconne c'est l'instruction suivante :
 
INSERT INTO `phpbb_smilies_tmp`
    SELECT s.smilies_id, (SELECT MIN(smilies_id) FROM `phpbb_smilies` s2 WHERE s2.emoticon = s.emoticon)
    FROM `phpbb_smilies` s;
 
Cette instruction vise, je pense, à mettre des objets de la table phpbb_smilies dans la table phpbb_smilies_tmp, avant l'instruction d'après, qui réorganise le tout... C'est encore obscur, désolé. Je continue à chercher

essaies cela stp

Merci betsamee, mais j'ai finalement reçu une solution de la part d'un type qui, comme moi, avait exactement le même problème.
 
J'ai trouvé son thread sur un forum russe, je lui ai écrit par mail, et il m'a donné sa méthode, ce qui ma foi est plutot cool (le thread date d'il y'a 2 ans )  
 
Ce qui est cool aussi, c'est l'aide que j'ai trouvée ici. Merci à tous les gars, je paierai pas ma soeur finalement (le voulais-je réellement ) !
 
Pour info, c'est donc un problème d'incompatibilité de MySQL version <4.1, qui n'accepte pas les requêtes imbriquées. Il fallait donc soit adapter le code, soit prendre une toute autre approche pour l'installation de la modification du forum. J'ai adopté la seconde solution, qui incluait l'effacement complet des 350 smileys que compte mon forum, et réinstallation ultérieure (ouch). Moins pratique, mais moins technique aussi.
 
Merci encore

moralité : tu vas envoyer ta soeur en russie ?

pour l'histoire des requêtes imbriquées, pour OVH j'ai été assez décu car avant de choisir un hébergeur j'avais bien regardé les descriptions techniques des offres, et OVH stipulait une version 4 de MySQL : ce n'est pas un mensonge, mais il aurait pu au moins spécifier la version mineure
 
Ce n'est qu'après avoir testé sur OVH que je m'étais rendu compte de la version de mysql j'avais du réadapter toutes mes requêtes

en mutualise OVH donne une version de MySQL < 4.1.9 ???    
nous sommes chez eux en dedie pour un de nos sites et nous avons du d'emblee changer la version de MySQL (3 quelquechose, une honte!)
Bref MySQL sans les requetes imbriquees ca vaut pas grand chose et je n imagine plus trop en passer
 
En dehors de ca je pense que ma solution marche donc je veux ta soeur clone de emmanuelle beart

bin non c'est du 4 par défaut chez OVH maintenant.

 
Comme je n'ai pas essayé ta requête, et que maintenant vu que tout marche je ne risque pas de l'essayer (j'ai trop peur que ça fasse une couille, excuse moi mais j'y connais rien moi ), je vais te laisser le bénéfice du doute, on va dire que ta requête marchait.  
 
A présent si tu veux bien, il faudrait me fournir les informations suivantes, c'est pour ma soeur :
 
Nom, prénom
Age
Taille / Poids
Couleur des cheveux
Couleur des yeux
Mensurations (toutes celles que tu jugeras utiles)
Statut / Nombre d'enfants (reconnus ou non)
Loisirs (hormis informatique)
 
Ma soeur étudiera ton dossier et t'enverra une réponse sous peu
 
C'est bon, là, j'ai bien botté en touche ?

t'as super bien botté en touche : dans un forum d'informaticiens, le fait de demander "loirsirs hormis informatique" t'as permis de virer la moitié des prétendants