Discussion :

[droliprane]

Bonjour,

je rencontre un problème auquel je devais m'attendre. Jusqu'à présent je n'avais pas beaucoup de données dans ma base, une centaine d'articles tout au plus. Et j'ai une procédure qui me sert à faire un calcul complet des couts de revient de mes articles. Et un article peut être fabriqué à partir d'autres articles.

J'ai donc une table art (mes articles) une table gam (succession d'opérations qui permettent de fabriquer un article donné) et une table nmcl (pour les liens de nomenclatures entre les articles, tel article est fabriqué à partir de telle quantité de tel autre article, etc...)

J'ai une procédure calculCOUT qui calcule le prix de revient net d'un article A à partir de sa gamme et de ses composants de nomenclature, et si le prix de A est différent de ce que j'avais jusqu'à présent dans la table art, alors je dois propager le nouveau coût de fabrication de A sur tous les articles qui utilisent A dans leur fabrication (je me sers des liens dans la table nmcl)

Le truc c'est que cette procédure de propagation du cout de A, entraine logiquement la modification du cout des articles parents (B, C, D, etc... il peut y en avoir beaucoup si A est une fourniture lambda utilisée dans la composition de beaucoup de produits) et ça devient vite exponentiel.

Alors déjà pour éviter les erreurs de contexte avec les noms des sources de données (que j'ai personnellement pris l'habitude d'appeler Rs pour Recordset), je fais des Rs += DonneIdentifiant() pour que mon recordset ne soit pas écrasé en mémoire au fur et à mesure des appels récursifs de ma procédure propageCOUT. Mais au bout d'un certain temps que le traitement mouline (pourtant il progresse, mais le processus gonfle en mémoire pour atteindre les 280Mo et c'est toujours au même moment que j'ai le crash) j'ai un plantage sur un HExecuteRequêteSQL :



Qu'est-ce que je peux faire pour libérer mieux mes Rs en fin de procédure ? Parce que je vois mon process WDTst augmenter sans jamais diminuer, preuve qu'il y a une mauvaise libération des ressources.

Merci d'avance pour toute aide apportée.

Bob

[tatayo]

Bonjour,
Sans voir le code, difficile de dire ce qui ne va pas (même si j'en connais un qui va accuser la récursivité en WinDev ...).

De toute façon je ne pense pas qu'un appel récursif "en force brut" soit la meilleur solution: si un produit A est composé des produits B et C, et que le prix de B et C est modifié, tu vas calculer 2 fois le prix de A...

Tatayo.

[Ry_Yo]

Comme dit tatayo, sans voir le code...

Je me lance quand même : avez-vous fermé vos requêtes par des HAnnuleDéclaration(rs) ?

[droliprane]

oui dans le fond tu as un peu raison, mais dans la pratique c'est plus compliqué de ne pas passer 2 fois sur un même article, à part gérer un tableau des références déjà traitées pour ne pas repasser dessus inutilement.

De plus, si j'ai deux articles A et Z utilisés dans la fabrication de l'article B, et que ma procédure de recalcul parcourt mes articles dans l'ordre alpha (pour schématiser, le même pb peut arriver en parcourant un id automatique), alors si je calcule le prix de revient de A, que celui-ci a changé, par conséquent cela entraine de recalculer le prix de revient de B. Ok, et si 500 articles plus tard je tombe sur Z, son prix de revient a changé également, je dois recalculer B alors !??

Enfin, la question de la récursivité peut être remise en cause, j'avais d'ailleurs initié un premier débat dans un de mes derniers sujets, mais c'est ce que j'ai trouvé de plus logique et de plus lisible pour coder ma fonctionnalité.

MAIS : je viens de rajouter à différents endroits des instruction HLibèreRequête(Rs) qui ont eu pour conséquence immédiate de faire que mon process WDTst.exe n'a cessé d'osciller entre 14 et 16 Mo ! Et mon traitement est allé jusqu'au bout.

Je ne sais pas si je peux considérer le sujet comme résolu, je me donne quelques jours de recul pour tester que ça fonctionne et que c'est stable.

En tout cas, même si je pensais que les ressources se libéraient automatiquement, dans un contexte particulier (ici les appels récusrsifs et l'empilage des contextes mémoires), il n'est vraiment pas superflux d'employer les instructions de libération telle que HAnnuleDéclaration et HLibèreRequête (qui d'ailleurs auraient le même effet d'après l'aide PCSoft ?)

EDIT : ci-dessous ma procédure coutDeRevient, même si je pense que pour vraiment comprendre, il faut être imprégné du modèle de données, ainsi que de la règle de gestion pour chiffrer un produit (somme des coûts de chaque opération de la gamme de fabrication = cout d'une heure d'atelier divisé par la cadence de fabrication d'une pièce, ou alors cout de sous-traitance si op sous-traitée, à laquelle on ajoute les couts de revient des fournitures employées à l'opération, etc...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
PROCEDURE coutDeRevient(aid est un entier, op est un entier)
 
Sql est une chaîne
Rs est une Source de Données
Rs2 est une Source de Données
cout_avant_op est un numérique
cout_op est un numérique
cout_apres_op est un numérique
cout_fournitures est un numérique
 
// on distribue sur les OP qui précedent celle donnée en paramètre (op)
 
cout_avant_op = 0
Sql = "SELECT * FROM gam, atl WHERE gam_article = " + aid + " AND gam_op_suivante = " + op + " AND gam_atelier = atl_id"
Rs += DonneIdentifiant()
SI PAS HExécuteRequêteSQL(Rs,Cnx,hRequêteDéfaut ,Sql) ALORS
	Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo()+ RC + RC + Sql)
	RENVOYER "ERREUR DANS PROCEDURE verifierGamme"
FIN
SI HLitPremier(Rs) ALORS
 
	// sommes des couts des op qui précèdent (qui pointe directement vers l'op)
	TANTQUE PAS HEnDehors(Rs)
		cout_avant_op = cout_avant_op + coutDeRevient(aid, Val(Rs.gam_op))
		//trace(OP + " " + cout_avant_op)
		HLitSuivant(Rs)
	FIN
 
FIN
 
HLibèreRequête(Rs)
 
SI op = 0 ALORS
	// UPDATE DU PRIX DE REVIENT DE L'ARTICLE
	Sql = "UPDATE art SET art_prix_revient = " + cout_avant_op + " WHERE art_id = " + aid
	SI PAS HExécuteRequêteSQL("Update",Cnx,hRequêteDéfaut ,Sql) ALORS
		Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo()+ RC + RC + Sql)
	FIN
 
	// et on renvoye le cout
	RENVOYER cout_avant_op
 
FIN
 
Sql =  "SELECT * FROM gam, atl WHERE gam_article = " + aid + " AND gam_op = " + op + " AND gam_atelier = atl_id"
Rs += DonneIdentifiant()
SI PAS HExécuteRequêteSQL(Rs,Cnx,hRequêteDéfaut ,Sql) ALORS
	Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo()+ RC + RC + Sql)
	RENVOYER "ERREUR DANS PROCEDURE verifierGamme"
FIN
SI HLitPremier(Rs) ALORS
 
	SI Rs.gam_atelier = 1 ALORS
		//straitance
		cout_op = Rs.gam_cout
	SINON
		// cadence interne
		cout_op = Rs.atl_taux / Rs.gam_cadence
	FIN
 
	cout_fournitures = 0
	Sql = "SELECT * FROM nmcl, art WHERE nmcl_article = " + aid + " AND nmcl_op = " + op + " AND nmcl_fourniture = art_id"
	//trace(Sql)
	Rs2 += DonneIdentifiant()
	SI PAS HExécuteRequêteSQL(Rs2,Cnx,hRequêteDéfaut ,Sql) ALORS		
		Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo()+ RC + RC + Sql)
		RENVOYER "ERREUR DANS PROCEDURE verifierGamme"
	FIN
	SI HLitPremier(Rs2) ALORS
		TANTQUE PAS HEnDehors(Rs2)
			//trace(Rs2.art_reference + " " + Rs2.nmcl_qte_lien + " x " + Rs2.art_prix_revient)
			cout_fournitures = cout_fournitures + (Rs2.nmcl_qte_lien * Rs2.art_prix_revient)
			HLitSuivant(Rs2)
		FIN
	FIN
	cout_op = cout_op + cout_fournitures
	cout_apres_op = cout_avant_op + cout_op
 
	HLibèreRequête(Rs2)
 
	// met à jour les infos dans la gamme
	Sql = "UPDATE gam SET gam_cout_avant_op = " + cout_avant_op + ", gam_cout_op = " + cout_op + ", gam_cout_apres_op = " + cout_apres_op + " WHERE gam_article = " + aid + " AND gam_op = " + op
	SI PAS HExécuteRequêteSQL("Update",Cnx,hRequêteDéfaut ,Sql) ALORS
		Erreur("Erreur d'initialisation de la requête"+RC+HErreurInfo()+ RC + RC + Sql)
	FIN
 
FIN
 
HLibèreRequête(Rs)
 
RENVOYER cout_apres_op

[Ry_Yo]

Pour moi ce n'est pas superflu mais un principe de base avec Windev.

Un appel à un sqlExec(), HExecuteXXX() entraine obligatoirement une fermeture de requête. je considère cela comme une faute lorsque je fais de la revue de code.

un cas concret sur AS/400 : un update d'un uniquement enregistrement causait une fuite mémoire à 500Mo. Après avoir simplement fermé la requête, la RAM restait à un niveau correct (en-dessous de la centaine de Mo)

[droliprane]

En attendant, je dois passer en revue toutes mes sources et chasser les Rs mal libérés

bon cette fois je mets mes lunettes

[Christophe.LOGEL]

Astuce : Charger les éléments en mémoire dans un tableau de structures et utiliser la procédure récursive sur le tableau de structures plutôt que des requêtes imbriquées. Gain de vitesse minimum X10.

[Nicolas_Jeanneau]

oui dans le fond tu as un peu raison, mais dans la pratique c'est plus compliqué de ne pas passer 2 fois sur un même article, à part gérer un tableau des références déjà traitées pour ne pas repasser dessus inutilement.

Personnellement pour répondre à cette problématique, j'ai constitué une table intermédiaire avec ma liste d'articles triée dans l'ordre de calcul :
Premièrement, tu ajoutes dans cette table la liste des articles qui ne sont pas fabriqués à partir d'articles. Ensuite, de façon récursive, tu ajoutes ceux qui ne sont constitué que d'articles présents dans la table intermédiaire.

Une fois la liste établie, il ne reste plus qu'à la parcourir dans le bon sens et appliquer les nouveaux coûts qui se cascaderont tous seuls et une seule fois.

Bon courage,

Nicolas

[laurent30s]

Je n'ai pas ton analyse, mais il me semble que ce type de calcul devrait pouvoir être fait en une seule requête
Ça réduit fortement le trafic sur le réseau et surtout tu évites les boucles de parcours très consommatrices...

Tu as lancé l'analyseur de performance pour voir où se consomme le temps ?

[Tober]

Pour les questions de libérations de mémoire, c'est logique que ton process gonflait avant.
La libération de ressources se fait (si pas d'appel à la fonction de libération) à la fin de ta fonction (ou du contexte d'exécution).
Vu que toi tu ne sors pas de la fonction mais fais de la récursivité, tu ne libéreras jamais les ressources tant que tout ton process n'est pas terminé, d'où le gonflement.

Comme l'a dit Ry_Yo, libérer la mémoire après l'exécution d'une requête est la première chose à faire après la récupération des données.

[droliprane]

Personnellement pour répondre à cette problématique, j'ai constitué une table intermédiaire avec ma liste d'articles triée dans l'ordre de calcul :
Premièrement, tu ajoutes dans cette table la liste des articles qui ne sont pas fabriqués à partir d'articles. Ensuite, de façon récursive, tu ajoutes ceux qui ne sont constitué que d'articles présents dans la table intermédiaire.

Une fois la liste établie, il ne reste plus qu'à la parcourir dans le bon sens et appliquer les nouveaux coûts qui se cascaderont tous seuls et une seule fois.

Bon courage,

Nicolas

Bonjour Nicolas,

donc si je comprends bien je récupère d'abord dans un tableau tous les articles qui se trouvent aux feuilles de tous mes arbres schématisant les liens de nomenclature (plus formellement : tous les articles de la table art qui ne sont pas définis comme composé dans la table nmcl (composé, composant, qté, um))
ensuite, récursivement, je complète le tableau par les articles qui utilisent ceux déjà présents dans le tableau, etc... jusqu'au produit fini

je pense qu'il faut faire attention à ne pas mettre deux fois le même article (rencontrés au cours du parcourt récursif partant de n composants différents mais aboutissant à un même produit fini ou semi-fini)

au final j'ai quand même de la récursivité, et des tests d'appartenance à un tableau qui peut s'avérer vite énorme, mais là où ça peut devenir intéressant c'est que le calcul du coût de revient se réduira ensuite à la somme des couts de ses composants, augmenté du cout de production de l'article en question, et pas besoin de propager le cout sur les parents, ce se fera naturellement ensuite. je vais tester ça quand j'aurai un peu de temps


J'en profite pour vous demander une chose, j'ai reçu une notification par mail d'un membre du forum qui a posté une réponse dans ce sujet, mais je ne retrouve pas son intervention dans le fil de notre discussion. Il me mettait en garde sur la limitation de WinDev au niveau des appels récursifs, qui d'après lui seraient limités au nombre de 20. Est-ce bien le cas ?

[Nicolas_Jeanneau]

je pense qu'il faut faire attention à ne pas mettre deux fois le même article (rencontrés au cours du parcourt récursif partant de n composants différents mais aboutissant à un même produit fini ou semi-fini)

Tu ne peux pas le mettre 2 fois !

Tu fais une requête avec les articles qui ne sont pas composants dans la table nmcl (tes feuilles en effet). Tu les ajoutes à ta table temporaire. Ensuite tu fais une requête des articles composés entièrement à partir d'articles présents dans la table temporaire. Tu ne devrais pas pouvoir ajouter 2 fois le même article en faisant comme cela.

[droliprane]

Je ne suis pas sur de bien comprendre alors.

Si j'ai mis dans ma table temporaire comme articles "feuilles" les articles suivants : vis, ressort, goupille

en cherchant les articles fabriqués à partir de l'article "ressort", je vais peut-être retomber sur des articles utilisant déjà "vis" dans leur nomenclature, et que j'aurai donc déjà ajouté à ma table lors du premier passage sur l'article "vis"

Ca me semble logique, mais c'est peut-être que toi tu n'as pas compris que dans mon cas, une même référence d'article peut être employée dans la composition de plusieurs produits...

[tatayo]

Pour ma part, j'aurai utilisé une requête récursive, qui m'aurait directement indiqué pour chaque produit son "niveau max" dans l'arborescence (le produit fini en 1).
Il suffit ensuite de trier cette requête par ordre décroissant, et de traiter les articles un par un.
Mais je doute que HF supporte les requêtes récursives...

On peut le faire par code: avec la procédure récursive, tu récupères tes articles et leur niveau, et tu stockes le tout dans un tableau (par exemple un tableau de structure, avec l'id et le rang).
Donc si tu rencontres 2 fois le même article, il ne faut le garder qu'une seule fois dans le tableau, avec le rang le plus élevé (entre le calcul et le rang déjà présent dans le tableau).

Ensuite tu tries le tableau sur le rang par ordre décroissant, et ensuite tu n'as plus qu'à le parcourir et calculer le prix des articles. Les dépendances sont déjà résolues.

Tatayo.

[droliprane]

c'est une idée intéressante sauf qu'à mon avis, si on fait démarrer le produit fini en 1 ça ne fonctionnera pas.

Exemple avec 2 arborescences de produit :

1 BOUCLE DE CEINTURE
- 2 COIFFE USINEE SOUDEE (x1)
-- 3 COIFFE (x1)
--- 4 LOPIN LAITON (x1)
-- 3 PION (x1)
- 2 EMBASE (x1)
-- 3 PROFILE LAITON (x1)
- 2 AXE (x1)
- 2 GOUPILLES (x2)


1 BRACELET
- 2 DEMI-LUNE MALE
-- 3 AXE (x1)
- 2 DEMI-LUNE FEMELLE
-- 3 AXE (x1)


On voit bien que si on numérote en partant du haut, on va se retrouver avec l'article "AXE" qui sera en profondeur 2 ou en profondeur 3

Par contre dans l'autre sens, je veux bien. En partant des feuilles vers les branches pour arriver aux différentes "racines" (mes produits finis) alors j'aurai une numérotation convenable

Ensuite je trie mes articles par ordre croissant, donc en premier je valorise le cout des composants les plus bas, et en avançant, les articles que je vais rencontrer seront forcément composés d'articles que j'aurai déjà valorisé...

Je vais tester ça

[droliprane]

arf ça ne va pas non plus

selon la feuille de laquelle je pars je ne vais pas atteindre un nœud avec la même profondeur, exemple :

  boucle usinée soudée  
    |                     |
axe poli         coiffe soudée
  |                         |
axe            pion ------- coiffe usi
                                       |
                                   meplat laiton

selon que je pars de l'"axe", ou bien du "méplat laiton", ma "boucle usinée soudée" n'a pas le même indice.....

je m'arrache les cheveux

[droliprane]

Alors quand un cas comme celui-là se présente, je prends la profondeur la plus haute. Comme ça quand je parcours mon tableau trié, au moment où je rencontrerai ma "boucle usinée soudée" alors je serai sur d'avoir déjà valorisé ses composants directs (le niveau juste en dessous). Ca vous semble correct comme méthode ? On va y arriver

[tatayo]

C'est un peu ce que j'ai expliqué... prendre le rang le plus haut pour chaque produit. Dans l'exemple précédent, AXE est en rang 3.
Donc le calcul sera dans l'ordre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
LOPIN LAITON (rang 4)
 
AXE (rang 3)
COIFFE (rang 3)
PION (rang 3)
PROFILE LAITON (rang 3)
 
COIFFE USINEE SOUDEE (rang 2)
DEMI-LUNE FEMELLE (rang 2)
DEMI-LUNE MALE (rang 2)
EMBASE (rang 2)
GOUPILLES (rang 2)
 
BOUCLE DE CEINTURE (rang 1)
BRACELET (rang 1)

Tatayo.

[droliprane]

ok donc :

- soit je pars des produits finis, et je vais en direction des composants, en numérotant de manière croissante, et si en partant d'un autre produit fini je rencontre un composant déjà rencontré, je lui affecte la profondeur la plus grande
- soit je pars des fournitures "feuilles" et je vais en direction des produits finis, en numérotant toujours de manière croissante, et si je rencontre un semi-fini déjà rencontré précédemment, à nouveau je lui accorde la profondeur de poids la plus haute

en fait peu importe l'ordre de numérotation, du moment qu'on trie ensuite le tableau obtenu selon cet ordre

je crois que c'est plus clair dans ma tête. Bon, même si on est toujours en récursif (un peu obligé vu le contexte), on gagne au moins le fait de ne plus repasser inutilement sur des nœuds déjà visités

EDIT : je viens de relire les quelques messages d'avant, et effectivement tatayo, ce que j'ai mis 3 messages à découvrir, est exactement ce que tu as expliqué toute à l'heure. excuse-moi je crois qu'il fallait que je sois confronté aux problèmes pour arriver à ta solution !

[droliprane]

et maintenant que j'y pense, un des autres avantages de passer par ce tableau intermédiaire, c'est que je vais pouvoir connaître à l'avance le nombre d'articles impactés par le recalcul (dans le cas où je ne modifie le prix que d'un seul composant)

et donc pouvoir mettre une jauge qui a du sens, avec un pourcentage, plutôt qu'un va-et-vient, étant donné qu'avec la récursivité on ne sait jamais vraiment où on en est dans le parcours global...