Discussion :

[Vincinho]

Bonjour tout le monde !!

J'ai un problème dans une requête assez complexe à expliquer. Je vais tout de même essayer, nous utilisons donc un ERP et pouvons créer une commande. Dans celle ci nous ajoutons des articles qui génèrent donc des achats. Ces achats sont rattachés à une affaire.

Tout est géré par des tables SQL COMC pour les lignes de commande, ACHIMP pour les lignes d'achats imputés (rattachés) a l'affaire et ACHE pour les achats.

J'ai déjà créé une requête mais il doit y avoir un problème dans le WHERE de mon UPDATE car aucune modification n'est appliquée.

Voila ma requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
SER("","select distinct nocommandeachat from achimp where nocommandeachat=@i33101$","vu$(2)")
 
SER("","UPDATE comc SET datefinprodplustard=(SELECT datesouhaiteeplustard  FROM achc  WHERE achc.codefourniprestto=comc.codearticleprestto  AND numeroachat=@vu$(2) )  
WHERE numeroaffairefils in (select numeroaffaire from achimp where nocommandeachat=@vu$(2) ) 
AND EXISTS (SELECT NULL  FROM achc WHERE achc.codefourniprestto=comc.codearticleprestto AND numeroachat=@vu$(2) )","")

vu$(2) est une variable utilisé qu'on peut utilisé dans l'ERP.

Merci de votre aide !!

[pacmann]

Salut !

Est-ce que tu as essayé de lancer les requêtes directement par ton client SQL ?

Est-ce que tu es capable d'afficher le contenu de vu$(2) après exécution de la première commande ?

Je pense que ton problème est clairement lié à l'utilisation de ton ERP (syntaxe du passage de paramètre, ... ?) et ça va être difficile de t'aider si la requête "brute" fonctionne de son côté...

[Vincinho]

En fait la requête fonctionnait bien mais je me suis rendu compte que le lien ne suffit pas car dans la commande on met des articles alors que dans l'achat on met des fournitures. En fait on a une table d'articles mais un article peut être acheté via différents fournisseurs donc il y a une table de fournitures qui fait le lien avec l'article. J'ai donc transformé ma requête qui devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SER("","select distinct nocommandeachat from achimp where nocommandeachat=@i33101$","vu$(2)")
 
SER("","UPDATE comc SET datefinprodplustard=(SELECT distinct datesouhaiteeplustard  FROM achc,fur  WHERE achc.codefourniprestto=fur.codefourniture and comc.codearticleprestto=fur.codearticleinterne  AND numeroachat='AC10_00814' )  
WHERE numeroaffairefils in (select numeroaffaire from achimp where nocommandeachat='AC10_00814' ) 
AND EXISTS (SELECT distinct NULL  FROM achc,fur WHERE achc.codefourniprestto=fur.codefourniture and comc.codearticleprestto=fur.codearticleinterne  AND numeroachat='AC10_00814' )","")

Cependant ca provoque une erreur car dans un cas précis, si un achat (AC10_00817 par exemple) a 2 lignes avec le même code fourniture et que c'est pour deux commandes et donc 2 affaires différentes, la sous requête renvoie 2 résultats.

Je ne vois pas comment faire pour éviter ce problème ?

Pour pacmann : quand on voit AC10_00814 c'est en fait le contenu de vu$(2) donc ca fonctionne bien.

Je pense que le problème vient de créer un lien entre l'achat et la commande car il n'y a normalement aucun rapport entre les deux. On en a créé un du fait qu'on ne créé qu'une seule commande pour une affaire donc une commande correspond forcément à une affaire et a partir de la on peut faire un lien mais dans le cas précisé au dessus je ne vois pas comment faire.

Si besoin de plus d'explications n'hésitez pas

[pacmann]

Tu as déjà essayé de lire tes explications ?
Tu imagines si on te réponds en une seule phrase sans ponctuation pour expliquer une solution ?

Je te propose une méthode : quand tu écris, relis en imaginant que c'est toi qui dois comprendre sans aucune connaissance du sujet.

Sinon, si tu as des problèmes de doublons, soit tu peux définir fonctionnellement un critère déterminant, soit tu veux en prendre un arbitrairement (ce qui est un peu louche quand même).

Dans ce cas, dans la sous requête de ton SET, mets un "max(...)" pour garantir l'unicité...