Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Requete MySQL WD8- 315j

8 réponses
Avatar
I.G.LOG
Bonjour,

J'ai une erreur que je n'arrive pas a expliquer sur la requete suivante:

select OL.IDOL, OL.TYPEPRE, OL.OBSERV, PHASE.NUMPHA, PHASE.DESIGNATION,
SOCIETE.RAISON as SocieteRaison,
CLIENT.RAISON, FAMPRES.ABRPREST, ARTICLE.ABRCONST, ARTICLE.REFCONST,
ARTSERIE.NUMSERIE
from PRESTAT PRESTAT, PHASE PHASE, FAMPRES FAMPRES, SOCIETE SOCIETE,
ARTSERIE ARTSERIE,
DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.IDCLIENT =
DOSSIER.IDCLIENT,
OLPROLG OLPROLG left outer join ARTICLE ARTICLE on ARTICLE.IDARTICLE =
OLPROLG.IDARTICLE,
OL OL left outer join OLREPAR OLREPAR on OLREPAR.IDOL = OL.IDOL
where OL.TERMINE = 0 and OL.SUSPENDU = 0
and OL.NUMSOC = {pNumSoc}
...


qui renvoi le message:

Erreur de l'acces natif MySQL
Numero d'erreur=22
L'erreur suivante a ete renvoyee par la base donnes <localhost>:
Numero d'erreur <1064>
Message d'erreur:
You have an error in your syntax. chech the manual that corresponds to your
MySQL server for the right syntax to use near '.IDCLIENT), OLPROLG LEFT
OUTER JOIN ARTICLE ON(article.

Cette requette parametree fonctionne parfaitement quand je la lance par
SQLExec (donc en remplacant les parametres par de valeurs). Je ne comprends
pas pourquoi elle plante dans un iInitRequeteEtat(). Avec le parametre
hRequêteSansCorrection, l'erreur se deplace sur une autre clause de la
requete, clause qui semble elle aussi correcte (!?!)

Merci à tous ceux qui repondront (je suis bloque sur la majorite de mes
etats qui sont bases sur des requete parametrees !)
Phil

8 réponses

Avatar
Romain PETIT
I.G.LOG a utilisé son clavier pour écrire :

Bonjour,



J'ai une erreur que je n'arrive pas a expliquer sur la requete suivante:


[...]
DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.IDCLIENT > DOSSIER.IDCLIENT,



- tu es sûr que la clé IDCLIENT existe sous ce nom ?
- essaie de changer le nom de l'alias (pourquoi utiliser le même ?)
[...]
DOSSIER DS left outer join CLIENT CL on CL.IDCLIENT = DS.IDCLIENT,

Merci à tous ceux qui repondront (je suis bloque sur la majorite de mes
etats qui sont bases sur des requete parametrees !)



Utilise la ligne de commande MySQL pour tester ta requete

A+

--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Avatar
I.G.LOG
Bonjour Romain,
J'ai essayé de changer l'alias justement pour resoudre cette "enigme": sans
l'alias ou avec un autre alias, le probleme est identique !
IDCLIENT est bien la cle primaire de la table CLIENT (cette requete
fonctionne avec SQLExec)
Effectivement il faudrait que j'essaie en ligne de commande MySQL; mais je
ne suis pas familiarisé avec ces manipulations;
il faut executer mysqlbinmysql -u root, puis, ensuite, comment se
connecter a la base, executer la requete etc ?
Merci encore

"Romain PETIT" a écrit dans le message de
news:
I.G.LOG a utilisé son clavier pour écrire :

> Bonjour,

> J'ai une erreur que je n'arrive pas a expliquer sur la requete suivante:
[...]
> DOSSIER DOSSIER left outer join CLIENT CLIENT on CLIENT.IDCLIENT > > DOSSIER.IDCLIENT,

- tu es sûr que la clé IDCLIENT existe sous ce nom ?
- essaie de changer le nom de l'alias (pourquoi utiliser le même ?)
[...]
DOSSIER DS left outer join CLIENT CL on CL.IDCLIENT = DS.IDCLIENT,

> Merci à tous ceux qui repondront (je suis bloque sur la majorite de mes
> etats qui sont bases sur des requete parametrees !)

Utilise la ligne de commande MySQL pour tester ta requete

A+

--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)



Avatar
Manu Pavy
I.G.LOG wrote:

Bonjour Romain,
J'ai essayé de changer l'alias justement pour resoudre cette "enigme": sans
l'alias ou avec un autre alias, le probleme est identique !
IDCLIENT est bien la cle primaire de la table CLIENT (cette requete



L'erreur, précédemment citée provient de jointure multiple, l'accès
natif de WD n'en veux pas, c'est pourquoi, il faut passer par
hRequeteSansCorrection, reste à savoir ce qui bloque avec ce parametre.


fonctionne avec SQLExec)
Effectivement il faudrait que j'essaie en ligne de commande MySQL; mais je
ne suis pas familiarisé avec ces manipulations;
il faut executer mysqlbinmysql -u root, puis, ensuite, comment se
connecter a la base, executer la requete etc ?



Tu as MySQLControlCenter qui est très bien comme client
(http://www-fr.mysql.com/downloads/mysqlcc.html)


Manu
Avatar
Roumegou Eric
Il se trouve que I.G.LOG a formulé :
Bonjour Romain,
J'ai essayé de changer l'alias justement pour resoudre cette "enigme": sans
l'alias ou avec un autre alias, le probleme est identique !
IDCLIENT est bien la cle primaire de la table CLIENT (cette requete
fonctionne avec SQLExec)
Effectivement il faudrait que j'essaie en ligne de commande MySQL; mais je
ne suis pas familiarisé avec ces manipulations;
il faut executer mysqlbinmysql -u root, puis, ensuite, comment se
connecter a la base, executer la requete etc ?
Merci encore



Si tu travailles sur mySQL, il est indispensable que tu utilises un
frontal.
Je te conseille SQLyog mais tu peux regarder aussi mySQLCC ou
DBManager.

Tu mettras au point tes requetes avec ces frontaux ou tu deboggueras
ton application.
Quand ça plante, pas facile de voir où. Un versPressePapier puis un
coller puis une execution sous ton frontal te permettra d'y voir plus
clair.

Il y aussi les tenants de phpmyadmin mais je trouve cela plus compliqué
à installer et moins ergonomique.

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Avatar
I.G.LOG
Bonjour,
Bon, le problème vient d'ailleurs. Et j'en ai déjà parlé dans mes precedents
post et au ST PcSoft (pas de solution !)
Le probleme est sur les parametres initialises a NULL; ca plante la requete
!?!

Voici la requete complete, qui fonctionne avec SQLExec() et avec le frontal
MySQL (en remplacant les parametres {param} par une valeur)

select OL.IDOL, OL.TYPEPRE, OL.OBSERV,
PHASE.NUMPHA, PHASE.DESIGNATION,
SOCIETE.RAISON as SocieteRaison,
CLIENT.RAISON,
FAMPRES.ABRPREST,
ARTICLE.ABRCONST, ARTICLE.REFCONST,
ARTSERIE.NUMSERIE
from PRESTAT, PHASE, FAMPRES, SOCIETE, ARTSERIE,
DOSSIER left outer join CLIENT on CLIENT.IDCLIENT = DOSSIER.IDCLIENT,
OLPROLG left outer join ARTICLE on ARTICLE.IDARTICLE = OLPROLG.IDARTICLE,
OL left outer join OLREPAR on OLREPAR.IDOL = OL.IDOL
where OL.TERMINE = 0 and OL.SUSPENDU = 0
and OL.NUMSOC = {pNumSoc}
and OLPROLG.IDOL = OL.IDOL and OLPROLG.NUMGRP = 99 and OLPROLG.ETAT = 1 and
OLPROLG.NUMCONTROLE = OL.NUMCONTROLE and OLPROLG.NUMPHA = {pNumPha}
and DOSSIER.IDDOSSIER = OL.IDDOSSIER
and SOCIETE.NUMSOC = DOSSIER.NUMSOC
and PHASE.NUMPHA = OLPROLG.NUMPHA
and PRESTAT.IDPRESTAT = OLPROLG.NUMERO
and FAMPRES.FPCLEUNIK = PRESTAT.FPCLEUNIK
and ARTSERIE.IDARTSERIE = OLREPAR.IDARTSERIE
and ARTICLE.NUMCAT = {pNumCat}
and CLIENT.CLIENTETAT = {pTypeCli}
order by NUMPHA, IDOL

Si j'initialise tous les parametres (je passe une valeur non null), la
requete fonctionne avec hRequeteSansCorrection. Dans le cas contraire (au
moins 1 parametre a NULL) plantage !!!
Je ne sais plus comment regler ce probleme de requetes parametrees que
j'utilise dans des etats. J'avais commence a transformer les etats en ETATS
SUR CONNEXION ODBC OU AUTRE mais ca me fait un boulot d'enfer (+ 100 etats)
et en plus, dans ce type d'etats, on ne peut pas utiliser "MaSource", donc
pas de possibilité de recuperer les colonnes de la requete (faut creer des
champs lies invisibles etc...: probleme communique au ST pour lequel j'ai la
fameuse reponse: Votre description ne nous permet pas de comprendre...
veuillez nous envoyer votre disque dur pour examen :-)"
Si vous avez une idée pour m'eviter tout ce boulot...
Merci à tous
Avatar
Manu Pavy
I.G.LOG wrote:

Bonjour,
Bon, le problème vient d'ailleurs. Et j'en ai déjà parlé dans mes precedents
post et au ST PcSoft (pas de solution !)
Le probleme est sur les parametres initialises a NULL; ca plante la requete
!?!

Voici la requete complete, qui fonctionne avec SQLExec() et avec le frontal
MySQL (en remplacant les parametres {param} par une valeur)

select OL.IDOL, OL.TYPEPRE, OL.OBSERV,
PHASE.NUMPHA, PHASE.DESIGNATION,
SOCIETE.RAISON as SocieteRaison,
CLIENT.RAISON,
FAMPRES.ABRPREST,
ARTICLE.ABRCONST, ARTICLE.REFCONST,
ARTSERIE.NUMSERIE
from PRESTAT, PHASE, FAMPRES, SOCIETE, ARTSERIE,
DOSSIER left outer join CLIENT on CLIENT.IDCLIENT = DOSSIER.IDCLIENT,
OLPROLG left outer join ARTICLE on ARTICLE.IDARTICLE = OLPROLG.IDARTICLE,
OL left outer join OLREPAR on OLREPAR.IDOL = OL.IDOL
where OL.TERMINE = 0 and OL.SUSPENDU = 0
and OL.NUMSOC = {pNumSoc}
and OLPROLG.IDOL = OL.IDOL and OLPROLG.NUMGRP = 99 and OLPROLG.ETAT = 1 and
OLPROLG.NUMCONTROLE = OL.NUMCONTROLE and OLPROLG.NUMPHA = {pNumPha}
and DOSSIER.IDDOSSIER = OL.IDDOSSIER
and SOCIETE.NUMSOC = DOSSIER.NUMSOC
and PHASE.NUMPHA = OLPROLG.NUMPHA
and PRESTAT.IDPRESTAT = OLPROLG.NUMERO
and FAMPRES.FPCLEUNIK = PRESTAT.FPCLEUNIK
and ARTSERIE.IDARTSERIE = OLREPAR.IDARTSERIE
and ARTICLE.NUMCAT = {pNumCat}
and CLIENT.CLIENTETAT = {pTypeCli}
order by NUMPHA, IDOL

Si j'initialise tous les parametres (je passe une valeur non null), la
requete fonctionne avec hRequeteSansCorrection. Dans le cas contraire (au
moins 1 parametre a NULL) plantage !!!
Je ne sais plus comment regler ce probleme de requetes parametrees que
j'utilise dans des etats. J'avais commence a transformer les etats en ETATS
SUR CONNEXION ODBC OU AUTRE mais ca me fait un boulot d'enfer (+ 100 etats)
et en plus, dans ce type d'etats, on ne peut pas utiliser "MaSource", donc
pas de possibilité de recuperer les colonnes de la requete (faut creer des
champs lies invisibles etc...: probleme communique au ST pour lequel j'ai la
fameuse reponse: Votre description ne nous permet pas de comprendre...
veuillez nous envoyer votre disque dur pour examen :-)"
Si vous avez une idée pour m'eviter tout ce boulot...
Merci à tous




Effectivement, j'ai eu exactement le meme problème une fois, que j'ai
finalement réussi à contourner.
On se heurte à un double problème : WD à mis en place un système
(l'accès natif) nous permettant d'envoyer des parametres null, et
"modifie" la requete SQL en enlevant la condition correspondante.
Et, d'un autre coté, son accès natif est limité lors des jointures :
elles sont limités à deux.
2 solutions : soit tu programmes des requetes différentes (toi meme ou
par programmation : manipulation de chaine) et tu t'adresse directement
à MySQL (hRequeteSansCorrection). Soit tu enleves les jointures (ou tu
en laisses une seules) en passant par des condition de type WHERE (c'est
ce que j avais fait - car les jointures me le permettaient)
Bon courage, et bon dev.

Manu
Avatar
nwjb
Le Tue, 31 Aug 2004 11:18:34 +0200, I.G.LOG a écrit:

Bonjour,
Bon, le problème vient d'ailleurs. Et j'en ai déjà parlé dans mes
precedents
post et au ST PcSoft (pas de solution !)
Le probleme est sur les parametres initialises a NULL; ca plante la
requete
!?!

Voici la requete complete, qui fonctionne avec SQLExec() et avec le
frontal
MySQL (en remplacant les parametres {param} par une valeur)

select OL.IDOL, OL.TYPEPRE, OL.OBSERV,
PHASE.NUMPHA, PHASE.DESIGNATION,
SOCIETE.RAISON as SocieteRaison,
CLIE
...



Pour ce qui nous concerne:
.requête "standard" SQL comprise par WD (c'est à dire sans not exists ,
fonctions bizarres
du genre || , ...) : utilisation avec hRequetedefaut , et le paramètres
sont correctement
traités sur base WD ou autre (ORA dans notre cas). Les paramètres absents
sont correctement
traités. Seul pb signalé au ST: sur une requête update les paramètres ne
sont pas bien
traités si passés dans le hexecute , mais correctement si passés par
req.paramn=... puis
hexecuterequete sans paramètres sur la ligne.
.requête non "standard" au sens WD: utilisation d'ordres SQL spécifiques
ou requêtes SQL pures
avec hrequetesanscorrection , et il faut effectivement gérer les
"paramètres" soi même.


J.Bratières
Avatar
I.G.LOG
> Effectivement, j'ai eu exactement le meme problème une fois, que j'ai
finalement réussi à contourner.
On se heurte à un double problème : WD à mis en place un système
(l'accès natif) nous permettant d'envoyer des parametres null, et
"modifie" la requete SQL en enlevant la condition correspondante.
Et, d'un autre coté, son accès natif est limité lors des jointures :
elles sont limités à deux.
2 solutions : soit tu programmes des requetes différentes (toi meme ou
par programmation : manipulation de chaine) et tu t'adresse directement
à MySQL (hRequeteSansCorrection). Soit tu enleves les jointures (ou tu
en laisses une seules) en passant par des condition de type WHERE (c'est
ce que j avais fait - car les jointures me le permettaient)
Bon courage, et bon dev.

Manu



Bonjour
C'est bien mon probleme. Ces requetes sont utilisees (entre autre) dans des
"etats lies a une requete du projet". Et il n'existe pas de moyen de lier un
etat a un requete "dynamique" (sur zone memoire,vue,fichier HF mais pas sur
un parcours SQL). Le seul moyen que j'ai trouve et de transformer les etats
en ETAT SUR CONNEXION ODBC OU AUTRE mais ca necessite un travail enorme de
reprogrammation (+ de 100 etats); de plus, dans ce type d'etat, on ne peut
pas utiliser "MaSource" pour acceder aux colonnes du resultat de la requete,
ce qui impose de passer par des champs lies invisible...
Si vous avez d'autres idees pour me sortir de cette "impasse"
Merci a tous