Bonjour,
J'ai une requete UNION qui fonctionne sur mon poste local mais pas sur le
serveur. Le client est en version 5.1.11
Les versions des serveurs MySQL sont :
en local, version 4.1.22
sur le serveur, version 4.1.9-standard (sous Linux)
Voici la requete, très simple:
SELECT
ENS
FROM
(
(SELECT
ENSEMBLE AS ENS
FROM
artconst
WHERE
IDARTICLE = 0)
UNION ALL
(SELECT
ENSEMBLE AS ENS
FROM
artconst
WHERE
IDARTICLE <> 0
AND SYSTEMATIQUE = 1
GROUP BY ENS)
) AS TableVirt
GROUP BY
ENS
ORDER BY
ENS
Ce que je ne comprends pas, c'est que j'ai des requètes UNION du même type
et beaucoup plus complexes qui fonctionnent sur le serveur 4.1.9-Standard
sur Linux ?!!
Avez-vous une idée du problème ?
Merci à tous
Il va surement être nécessaire de faire un update du noyau avec une version plus récente. Normalement si on reste sur la même version 4.1, c'est très rapide à faire. Penser toutefois à faire une sauvegarde, et de ne pas effacer la version de prod (on ne sait jamais).
Bonjour, Je ne trouve rien dans les évolutions concernant les requetes UNION. De plus, je suis en train d'essayer sur un deuxième poste de dev. sur lequel est installé MySQL 4.1.22-community-nt, et j'ai cette erreur 1248 "Every derived..." ; alors que sur l'autre poste en 4.1.22 ça fonctionne ???!!! Postes de même config XP Pro SP2. Seul le processeur change Pentium 4 contre Athlon 2600+ Une idée ? Merci
Regardez le fichier de configuration qui lance le moteur, il est possible qu'il y ait des éléments qui diffèrent. Le fichier par défaut est my.ini.
Il me semble qu'à partir de la version 4.1.xx il y a l'option SQL_mode qui est apparu et qui fait que le moteur se comporte différemment (voir l'aide à ce sujet).
Je n'ai pas suivi tout le thread, mais si ce n'est pas le cas lancer la requête à partir de MySQL Query Browser.
Désolé mais pas le temps de regarder plus loin.
J'oubliais sur Linux MySQL est casse dépendant, enfin tout dépend du moteur, il y a un flag qui existe également sous Windows pour forcer le comportement.
Bref, bon courage.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Daniel a écrit :
I.G.LOG a écrit :
"Daniel" <nospam@wanadoo.fr> a écrit dans le message de news:
48e20826$0$1133$426a74cc@news.free.fr...
Bonjour,
MySQL 4.1.9 c'est peut être tout simplement qu'il y avait un bug sur
Union qui a été corrigé entre la version 4.19 et la 4.1.22.
Il va surement être nécessaire de faire un update du noyau avec une
version plus récente. Normalement si on reste sur la même version
4.1, c'est très rapide à faire. Penser toutefois à faire une
sauvegarde, et de ne pas effacer la version de prod (on ne sait jamais).
Bonjour,
Je ne trouve rien dans les évolutions concernant les requetes UNION.
De plus, je suis en train d'essayer sur un deuxième poste de dev. sur
lequel est installé MySQL 4.1.22-community-nt, et j'ai cette erreur
1248 "Every derived..." ; alors
que sur l'autre poste en 4.1.22 ça fonctionne ???!!!
Postes de même config XP Pro SP2. Seul le processeur change Pentium 4
contre Athlon 2600+
Une idée ?
Merci
Regardez le fichier de configuration qui lance le moteur, il est
possible qu'il y ait des éléments qui diffèrent.
Le fichier par défaut est my.ini.
Il me semble qu'à partir de la version 4.1.xx il y a l'option SQL_mode
qui est apparu et qui fait que le moteur se comporte différemment (voir
l'aide à ce sujet).
Je n'ai pas suivi tout le thread, mais si ce n'est pas le cas lancer la
requête à partir de MySQL Query Browser.
Désolé mais pas le temps de regarder plus loin.
J'oubliais sur Linux MySQL est casse dépendant, enfin tout dépend du
moteur, il y a un flag qui existe également sous Windows pour forcer le
comportement.
Bref, bon courage.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Il va surement être nécessaire de faire un update du noyau avec une version plus récente. Normalement si on reste sur la même version 4.1, c'est très rapide à faire. Penser toutefois à faire une sauvegarde, et de ne pas effacer la version de prod (on ne sait jamais).
Bonjour, Je ne trouve rien dans les évolutions concernant les requetes UNION. De plus, je suis en train d'essayer sur un deuxième poste de dev. sur lequel est installé MySQL 4.1.22-community-nt, et j'ai cette erreur 1248 "Every derived..." ; alors que sur l'autre poste en 4.1.22 ça fonctionne ???!!! Postes de même config XP Pro SP2. Seul le processeur change Pentium 4 contre Athlon 2600+ Une idée ? Merci
Regardez le fichier de configuration qui lance le moteur, il est possible qu'il y ait des éléments qui diffèrent. Le fichier par défaut est my.ini.
Il me semble qu'à partir de la version 4.1.xx il y a l'option SQL_mode qui est apparu et qui fait que le moteur se comporte différemment (voir l'aide à ce sujet).
Je n'ai pas suivi tout le thread, mais si ce n'est pas le cas lancer la requête à partir de MySQL Query Browser.
Désolé mais pas le temps de regarder plus loin.
J'oubliais sur Linux MySQL est casse dépendant, enfin tout dépend du moteur, il y a un flag qui existe également sous Windows pour forcer le comportement.
Bref, bon courage.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
I.G.LOG
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as TableVirt" :-( Là ca marche. Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas comme la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas en 4.1.9 !!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005: Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas faire l'essai tout de suite car c'est chez le client) Mais les autres requètes que tu m'as aidé à mettre au point ont des parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le programme chez le client ce matin sans problème. C'est ce que je ne comprend pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux postes ?!
Je vais continuer à creuser ça Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà ancien)
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as
TableVirt" :-(
Là ca marche.
Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas comme
la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas en 4.1.9
!!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005:
Modified the parser to allow SELECT statements following the UNION keyword
to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas
faire l'essai tout de suite car c'est chez le client)
Mais les autres requètes que tu m'as aidé à mettre au point ont des
parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le
programme chez le client ce matin sans problème. C'est ce que je ne comprend
pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux postes ?!
Je vais continuer à creuser ça
Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à
passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers
d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur
Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà
ancien)
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as TableVirt" :-( Là ca marche. Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas comme la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas en 4.1.9 !!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005: Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas faire l'essai tout de suite car c'est chez le client) Mais les autres requètes que tu m'as aidé à mettre au point ont des parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le programme chez le client ce matin sans problème. C'est ce que je ne comprend pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux postes ?!
Je vais continuer à creuser ça Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà ancien)
I.G.LOG
En fait ca marche bien en 4.1.22 : j'avais oublié sur mon test le ") as TableVirt" du select principal. Donc le problème se pose sur la 4.1.9. Mais il faut que je teste si ca ne vient pas des parenthèses sur les subqueries car, sur le lien que tu m'as donné, j'ai trouvé, lors de l'évolution 4.1.11 du 1/04/2005:
Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je te tiens au courant après mes essais Merci pour ta réponse
En fait ca marche bien en 4.1.22 : j'avais oublié sur mon test le ") as
TableVirt" du select principal.
Donc le problème se pose sur la 4.1.9. Mais il faut que je teste si ca ne
vient pas des parenthèses sur les subqueries car, sur le lien que tu m'as
donné, j'ai trouvé, lors de l'évolution 4.1.11 du 1/04/2005:
Modified the parser to allow SELECT statements following the UNION keyword
to be subqueries in parentheses. (Bug#2435)
Je te tiens au courant après mes essais
Merci pour ta réponse
En fait ca marche bien en 4.1.22 : j'avais oublié sur mon test le ") as TableVirt" du select principal. Donc le problème se pose sur la 4.1.9. Mais il faut que je teste si ca ne vient pas des parenthèses sur les subqueries car, sur le lien que tu m'as donné, j'ai trouvé, lors de l'évolution 4.1.11 du 1/04/2005:
Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je te tiens au courant après mes essais Merci pour ta réponse
Firetox
si tu met des paranthese il faut que chaque sous requete ai un alias si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera sur le select global (car il y a les paranthese) j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne sais plus entre quelle et quelle version les alias des sous requete sont generée si ils manque donc en 4.1.22 tu n'a pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le fait pas donc tu dois les mettre par defaut et pour plus de lisibilité je les met toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y avoir des alias si il y a des parantheses bon dev @+
"I.G.LOG" a écrit dans le message de news: 48e2339f$0$946$
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as TableVirt" :-( Là ca marche. Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas comme la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas en 4.1.9 !!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005: Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas faire l'essai tout de suite car c'est chez le client) Mais les autres requètes que tu m'as aidé à mettre au point ont des parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le programme chez le client ce matin sans problème. C'est ce que je ne comprend pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux postes ?!
Je vais continuer à creuser ça Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà ancien)
si tu met des paranthese il faut que chaque sous requete ai un alias
si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera
sur le select global (car il y a les paranthese)
j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne sais
plus entre quelle et quelle version
les alias des sous requete sont generée si ils manque donc en 4.1.22 tu n'a
pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le fait
pas donc tu dois les mettre par defaut et pour plus de lisibilité je les met
toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y
avoir des alias si il y a des parantheses
bon dev
@+
"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
48e2339f$0$946$ba4acef3@news.orange.fr...
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as
TableVirt" :-(
Là ca marche.
Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas
comme la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas
en 4.1.9 !!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005:
Modified the parser to allow SELECT statements following the UNION keyword
to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas
faire l'essai tout de suite car c'est chez le client)
Mais les autres requètes que tu m'as aidé à mettre au point ont des
parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le
programme chez le client ce matin sans problème. C'est ce que je ne
comprend pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux
postes ?!
Je vais continuer à creuser ça
Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à
passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers
d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur
Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà
ancien)
si tu met des paranthese il faut que chaque sous requete ai un alias si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera sur le select global (car il y a les paranthese) j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne sais plus entre quelle et quelle version les alias des sous requete sont generée si ils manque donc en 4.1.22 tu n'a pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le fait pas donc tu dois les mettre par defaut et pour plus de lisibilité je les met toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y avoir des alias si il y a des parantheses bon dev @+
"I.G.LOG" a écrit dans le message de news: 48e2339f$0$946$
Désolé, à cause de tous mes essais j'avais effectivement oublié le ") as TableVirt" :-( Là ca marche. Bon pour résumer, il semblerait que la version 4.1.9 ne "réagisse" pas comme la 4.1.22. En effet, la même requete fonctionne en 4.1.22 mais pas en 4.1.9 !!!
Information peut-être l'origine du problème:
Evolution 4.1.11 du 01/04/2005: Modified the parser to allow SELECT statements following the UNION keyword to be subqueries in parentheses. (Bug#2435)
Je vais essayer sans les parenthèses sur le serveur 4.1.9 (je ne peux pas faire l'essai tout de suite car c'est chez le client) Mais les autres requètes que tu m'as aidé à mettre au point ont des parenthèses à chaque subquerie, et fonctionnent en 4.1.9, j'ai exécuté le programme chez le client ce matin sans problème. C'est ce que je ne comprend pas !!! J'ai pourtant le même client 5.1.11 installé sur les deux postes ?!
Je vais continuer à creuser ça Merci beaucoup
PS: si je dois faire une mise à jour du serveur, y a t il un interet à passer en 5.1 ? Meilleures performances ? Est-ce que ca mérite les dangers d'un upgrade ? Est-ce compliqué ? (je ne l'ai pas fait car je suis sur Fedora Core 3 et je ne sais pas si la 5.1 est disponible sur ce Linux déjà ancien)
I.G.LOG
"Firetox" a écrit dans le message de news: 48e234ab$0$13005$
si tu met des paranthese il faut que chaque sous requete ai un alias si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera sur le select global (car il y a les paranthese) j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne sais plus entre quelle et quelle version les alias des sous requete sont generée si ils manque donc en 4.1.22 tu n'a pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le fait pas donc tu dois les mettre par defaut et pour plus de lisibilité je les met toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y avoir des alias si il y a des parantheses bon dev @+
D'accord, dès que je retourne chez le client je teste ça. Encore un grand merci pour tes précieux conseils Bon dev.
"Firetox" <firetox@SQLManagerX.com> a écrit dans le message de news:
48e234ab$0$13005$426a74cc@news.free.fr...
si tu met des paranthese il faut que chaque sous requete ai un alias
si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera
sur le select global (car il y a les paranthese)
j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne
sais plus entre quelle et quelle version
les alias des sous requete sont generée si ils manque donc en 4.1.22 tu
n'a pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le
fait pas donc tu dois les mettre par defaut et pour plus de lisibilité je
les met toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y
avoir des alias si il y a des parantheses
bon dev
@+
D'accord, dès que je retourne chez le client je teste ça.
Encore un grand merci pour tes précieux conseils
Bon dev.
"Firetox" a écrit dans le message de news: 48e234ab$0$13005$
si tu met des paranthese il faut que chaque sous requete ai un alias si tu ne met pas de paranthese l'alias n'est pas obligatoire mais le sera sur le select global (car il y a les paranthese) j'ai lu dans la doc qu'il avait fait quelque chose comme ca mais je ne sais plus entre quelle et quelle version les alias des sous requete sont generée si ils manque donc en 4.1.22 tu n'a pas besoin de les mettre il les rajoute par contre en 4.1.19 il ne le fait pas donc tu dois les mettre par defaut et pour plus de lisibilité je les met toujours
c'est peut etre pour ca que ca marche avec les autres requetes il doit y avoir des alias si il y a des parantheses bon dev @+
D'accord, dès que je retourne chez le client je teste ça. Encore un grand merci pour tes précieux conseils Bon dev.
