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

WD12/MySQL - Etat sur requete paramétrée

8 réponses
Avatar
I.G.LOG
Bonjour,
J'ai souvent posté ici sur mes difficultés avec les états basés sur une
requete paramétrée. Je suis en train une nouvelle fois de m'arracher les
cheveux:
J'ai un état qui refuse obstinément de m'afficher les données. J'ai le
message "sélection et tri des enregistrements en cours" pendant une seconde
puis retour au programme, aucun affichage !! J'ai utilisé toutes les options
d'affichage en cas de données inexistantes (dans détail/si la source de
données est vide) sans que ca influe le résultat. La requete est un peu
complexe (union all) mais je l'ai testée avec un frontal MySQL, elle renvoie
bien les données attendues. De plus si je teste l'état directement par "GO",
j'ai le même problème, avec la différence que la lecture des données est
beaucoup plus longue (une dizaine de secondes au lieu d'une)
Si quelqu'un a une idée sur le problème, ça m'arrangerait bien: je cherche
depuis 2 heures sans succès. De plus ce problème est récurrent, je le
rencontre régulièrement sans que je puisse en trouver l'origine.

Voici la requète (mais je ne pense pas que le problème vienne de là) qui
doit me renvoyer tous les articles en stock qui sont mouvementés durant une
période donnée:

SELECT
documlg.IDDOCUM,documlg.IDARTICLE,documlg.DESIGNATION,documlg.REFCONST,documlg.ETAT,
'E' AS TypeMvt, SUM(mouvement.QTE) AS Total,
tiers.RAISON
FROM
documlg,
mouvement,
tiers
WHERE
documlg.IDDOCUM IN ({pNumMag})
AND documlg.IDTIERS = {pConst}
AND documlg.REFCONST BETWEEN {pDe} AND {pA}
AND documlg.ETAT = {pEtat}
AND mouvement.DESTINATION = documlg.IDDOCUMLG
AND mouvement.DATEMVT BETWEEN {pDateDe} AND {pDateA}
AND tiers.IDTIERS = documlg.IDTIERS
GROUP BY
REFCONST,ETAT,TypeMvt,IDARTICLE,DESIGNATION,IDDOCUM,RAISON
HAVING
Total > 0
UNION all
SELECT
documlg.IDDOCUM,documlg.IDARTICLE,documlg.DESIGNATION,documlg.REFCONST,documlg.ETAT,
'S' AS TypeMvt, SUM(mouvement.QTE) AS Total,
tiers.RAISON
FROM
documlg,
mouvement,
tiers
WHERE
documlg.IDDOCUM IN ({pNumMag})
AND documlg.IDTIERS = {pConst}
AND documlg.REFCONST BETWEEN {pDe} AND {pA}
AND documlg.ETAT = {pEtat}
AND mouvement.ORIGINE = documlg.IDDOCUMLG
AND mouvement.DATEMVT BETWEEN {pDateDe} AND {pDateA}
AND tiers.IDTIERS = documlg.IDTIERS
GROUP BY
REFCONST,ETAT,TypeMvt,IDARTICLE,DESIGNATION,IDDOCUM,RAISON
HAVING
Total > 0
ORDER BY RAISON,REFCONST

Merci à tous

8 réponses

Avatar
I.G.LOG
suite...
je suis en train de travailler sur un autre état qui présente les mêmes
symptomes (pas d'impression)
au secours !!!
Avatar
I.G.LOG
Personne n'a jamais eu ce problème d'état qui ne s'imprime pas ?
PS: j'ai modifié la requete dans sa plus simple expression (cad sans
paramètres, réduite au maximum pour etre sur qu'elle renvoie un résultat)
sans que le problème soit réglé; ca ne vient donc pas de la requete.
Merci de me dire si quelqu'un a déjà rencontré ce problème et si il a une
idée pour y remédier
Avatar
jcd
I.G.LOG a écrit :
Personne n'a jamais eu ce problème d'état qui ne s'imprime pas ?
PS: j'ai modifié la requete dans sa plus simple expression (cad sans
paramètres, réduite au maximum pour etre sur qu'elle renvoie un résultat)
sans que le problème soit réglé; ca ne vient donc pas de la requete.
Merci de me dire si quelqu'un a déjà rencontré ce problème et si il a une
idée pour y remédier




Bonjours,
j'ai eu un problème similaire il y a peu: un état basé sur une requête
qui elle même filtrait les résultats d'une autre requête, les deux étant
paramétrées.

J'ai placé un délai de 0.5s ( fonction temporisation(50)) avant
d'exécuter la requête ( finale ), et çà marche chez moi.
En testant les requêtes seules, pas de problème, des résultats cohérents
étaient fournis.
Avatar
I.G.LOG
> Bonjours,
j'ai eu un problème similaire il y a peu: un état basé sur une requête qui
elle même filtrait les résultats d'une autre requête, les deux étant
paramétrées.

J'ai placé un délai de 0.5s ( fonction temporisation(50)) avant d'exécuter
la requête ( finale ), et çà marche chez moi.
En testant les requêtes seules, pas de problème, des résultats cohérents
étaient fournis.



Bonjour,
L'état utilise une requete unique, ce n'est donc pas le même problème.
Je suis en train de continuer mes essais; il semblerait que c'est le
iInitRequeteEtat() qui est à l'origine du problème: j'ai ajouté un
info("passe") dans le code d'initialisation de l'état. Quand je lance l'état
avec préalablement iInitRequeteEtat(), le code d'init de l'état n'est jamais
effectué (pas d'info("passe")), sans iInitRequeteEtat ce code est effectué
(info bien affiché) ?!
Par ailleurs, après avoir exécuté ces états qui posent problème, lorsque je
lance un autre état "valide" j'ai un message d'erreur "impossible d'imprimer
l'état, on attendait l'impression d'un autre état. Ce problème se
produit..."
Peut-être avez vous une idée du problème ?
Avatar
Moua
jcd a couché sur son écran :
I.G.LOG a écrit :
Personne n'a jamais eu ce problème d'état qui ne s'imprime pas ?
PS: j'ai modifié la requete dans sa plus simple expression (cad sans
paramètres, réduite au maximum pour etre sur qu'elle renvoie un résultat)
sans que le problème soit réglé; ca ne vient donc pas de la requete.
Merci de me dire si quelqu'un a déjà rencontré ce problème et si il a une
idée pour y remédier




Bonjours,
j'ai eu un problème similaire il y a peu: un état basé sur une requête qui
elle même filtrait les résultats d'une autre requête, les deux étant
paramétrées.

J'ai placé un délai de 0.5s ( fonction temporisation(50)) avant d'exécuter la
requête ( finale ), et çà marche chez moi.
En testant les requêtes seules, pas de problème, des résultats cohérents
étaient fournis.



Bonjour,

Je fait toujours des états avec la chaîne de caractères de l'ordre SQL
dans la propriété de l'état, sans passer par des requêtes.
Cela m'évite des prises de tête !
Avatar
I.G.LOG
> Je fait toujours des états avec la chaîne de caractères de l'ordre SQL
dans la propriété de l'état, sans passer par des requêtes.
Cela m'évite des prises de tête !



Bonjour,
Oui je crois que ce va être le meilleur moyen, car, en effet, le requetes
paramétrées sont souvent de grosses prises de tête.
Mais, si on les abandonne, on pert l'avantage de pouvoir les utiliser dans
d'autre traitements ! Bien dommage.
Je vais tout de même appeler le ST pour savoir si ils ont une solution de
contournement.
Merci pour vos réponses
Avatar
jcd
I.G.LOG a écrit :
Bonjours,
j'ai eu un problème similaire il y a peu: un état basé sur une requête qui
elle même filtrait les résultats d'une autre requête, les deux étant
paramétrées.

J'ai placé un délai de 0.5s ( fonction temporisation(50)) avant d'exécuter
la requête ( finale ), et çà marche chez moi.
En testant les requêtes seules, pas de problème, des résultats cohérents
étaient fournis.



Bonjour,
L'état utilise une requete unique, ce n'est donc pas le même problème.
Je suis en train de continuer mes essais; il semblerait que c'est le
iInitRequeteEtat() qui est à l'origine du problème: j'ai ajouté un
info("passe") dans le code d'initialisation de l'état. Quand je lance l'état
avec préalablement iInitRequeteEtat(), le code d'init de l'état n'est jamais
effectué (pas d'info("passe")), sans iInitRequeteEtat ce code est effectué
(info bien affiché) ?!
Par ailleurs, après avoir exécuté ces états qui posent problème, lorsque je
lance un autre état "valide" j'ai un message d'erreur "impossible d'imprimer
l'état, on attendait l'impression d'un autre état. Ce problème se
produit..."
Peut-être avez vous une idée du problème ?




bonsoir, similaire ne sous entend pas identique, c'était une bête
proposition de ma part. Désolé!
Avatar
I.G.LOG
> bonsoir, similaire ne sous entend pas identique, c'était une bête
proposition de ma part. Désolé!



Bonjour,
Après recherches approfondies, le problème vient de la requète qui
fonctionne en mode test (test depuis le code de la requète) et avec un
frontal MySQL, mais pas avec hExecuteRequete(), avec ou sans la constante
hSansCorrection !!!???
J'ai communiqué ce problème au ST, j'attend leur réponse.
En tous cas, merci pour vos réponses