En fait, la vraie question est: pourquoi utilises-tu MySQL 3.23 ? D'après ce que je me rappelle, l'optimiseur de requête de la 3.23 est moins évolué que celui des versions qui l'ont précédé (4.0, 4.1, 5.0) donc ça ne va pas trop avec "plusieurs dizaines e tables avec des requêtes complexes".

À part ça, je dirais que c'est soit un bug™ soit une confusion entre la valeur [b]1[/b] et l'ancienne notation numérique des champs (où [b]1[/b] signifie "le premier champs de la tables", notation abandonnée depuis), même si dans ce cas le résultat devrait être différent... En règle générale je recommande de ne [b]pas[/b] utiliser de valeurs numériques telles quelles, mais d'utiliser un opérateur tel que "CAST(1 AS INT)" mais CAST() n'existe qu'à partir de la 4.0... désolé, mais je pense que tu as le choix entre mettre à jour le serveur (de loin la meilleure solution) ou utiliser un [i]hack[/i] comme celui que tu as posté. Et puisque les résultats renvoyés par les fonctions MySQL de PHP sont toujours des chaînes tu peux utiliser quelque chose comme:
[code]SELECT `c1`, `c2`, `c3`, '1' FROM `t`;[/code]

Et puisque tu n'as que trois champs, qu'est-ce qui t'empêche de faire simplement :
[code]SELECT `c1`, `c2`, `c3` FROM `t`;[/code]
:?:

Bonsoir,

je viens de rencontrer un problème sur un projet assez important (plusieurs dixaines de tables avec requêtes complexes) et après plusieurs tests, j'ai isolé une requête simple mais buggée :

SELECT `c1`, `c2`, `c3`, 1 FROM `t`;

Réponse obtenue :

[code]c1 | c2 | c3 | 1
l1c1 | 1 | l1c3 | 1[/code]

Réponse attendue :

[code]c1 | c2 | c3 | 1
l1c1 | l1c2 | l1c3 | 1[/code]

Pour le contexte, voici la création et le remplissage de la table :

CREATE TABLE `t` (`c1` VARCHAR(10), `c2` VARCHAR(10), `c3` VARCHAR(10));
INSERT INTO `t` (`c1`, `c2`, `c3`) VALUES ('l1c1', 'l1c2', 'l1c3');

Constatez-vous le même bug ?

Julien

PS : En exécutant la requête suivante, plus de bug !!!

SELECT `c1`, `c2`, `c3`, 1*1 FROM `t`;