Je rencontre un petit souci.
Soit une table de produits composés de Matières et/ou de Bases
Une base peut être composée de Matières et/ou de Bases
En gros :
P1
--B1
----M2
----M3
----M4
--M2
--M26
--M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du
classique que je sais faire. MAIS les données sont dans une base SQL et
ma fonction récursive se plante. A l'affichage je n'ai que :
P1
--B1
----M2
----M3
----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça
plante. Maintenant j'incrémente le n° à chaque appel récursif et ça
plante toujours.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Lecoester
"Stéphane Miqueu" a écrit dans le message de news:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
Comme répondu sur le forum du site (parce que si je dit la réponse est sur le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options : - requete avec auto-jointure(s) - utilisation de SQLManagerX qui possède les méthodes SauvePosition et RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes migrations de projet. Le fait de tout mettre dans une requete assure : un temps de réponse constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base de données (du moment que les indexes existent). Seule contrainte : si ta recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre (construction de ta requete), si elle possède une profondeur maxi, suffit de faire n+1 jointure :)
Voilà : à toi de faire ton choix :)
Bienvenue parmi nous "
++
"Stéphane Miqueu" <stephane.miqueu@free.fr> a écrit dans le message de
news:mn.23db7d6439380cf2.49235@free.fr...
Bonjour,
Je rencontre un petit souci.
Soit une table de produits composés de Matières et/ou de Bases
Une base peut être composée de Matières et/ou de Bases
En gros :
P1
--B1
----M2
----M3
----M4
--M2
--M26
--M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du
classique que je sais faire. MAIS les données sont dans une base SQL et
ma fonction récursive se plante. A l'affichage je n'ai que :
P1
--B1
----M2
----M3
----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça
plante. Maintenant j'incrémente le n° à chaque appel récursif et ça
plante toujours.
Des idées ?
Comme répondu sur le forum du site (parce que si je dit la réponse est sur
le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options :
- requete avec auto-jointure(s)
- utilisation de SQLManagerX qui possède les méthodes SauvePosition et
RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes
migrations de projet.
Le fait de tout mettre dans une requete assure : un temps de réponse
constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base
de données (du moment que les indexes existent). Seule contrainte : si ta
recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre
(construction de ta requete), si elle possède une profondeur maxi, suffit de
faire n+1 jointure :)
"Stéphane Miqueu" a écrit dans le message de news:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
Comme répondu sur le forum du site (parce que si je dit la réponse est sur le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options : - requete avec auto-jointure(s) - utilisation de SQLManagerX qui possède les méthodes SauvePosition et RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes migrations de projet. Le fait de tout mettre dans une requete assure : un temps de réponse constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base de données (du moment que les indexes existent). Seule contrainte : si ta recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre (construction de ta requete), si elle possède une profondeur maxi, suffit de faire n+1 jointure :)
Voilà : à toi de faire ton choix :)
Bienvenue parmi nous "
++
Firetox
Bonjour,
manu a raison et tord. raison car il est plus facile pour lui de le faire directement en acces natif avec 1 requete.
maintenant je ne vois pas ce qui genrait de le faire en SQLManagerX.j'utilise dans le data center une base pour gerer le treeview et dans le chargment pas de probleme. dans ta desription sur le site SQLManagerX tu parle de n° de requete donc tu passe par l'acces natif. sinon SQLManagerX ouvre et ferme les requete a chaque fois donc pas de gene de ce cote la. si on utilise SQLPremier et SQLSuivant, le N° de requete est referme a chaque fois donc il serait possibile de le faire et le data center le fais bien.
maintenant je pense qu'il faut plutot que tu t'oriente vers 1 requete et parcours de cette requete sinon passe en SQLManagerX et faire des filtres sur les tables et utiliser sauvePosition et retourPosition puisque tu utilise la meme table ou sinon utiliser un autre objet sur la table
rien n'empeche d'instancier un objet SQLManagerX au moment ou tu en a besoin.
bref tout depend aussi de comment est fait la table, et comme est stocké la hierarchisation
deuxieme point a eviter : la recursivite sous windev elle est limite. faites un test sur la multiplication chinoise pour voir combien d'appel on peu avoir avant d'exploser la pile
voici a procedure : FUNCTION multiplication(vA , vB) SI vB > 0 ALORS RENVOYER(vA+multiplication(vA,vB-1)) SINON RENVOYER vB
et l'appel : v_res est un entier v_res = multiplication(1,842) Trace(v_res)
en Windev 7.5 842 appels est le maximum si jamais vous mettez 843 ca plante donc mef avec le recursif
bref il y a surement une solution maintenant voir quelle option tu veux prendre
@+
donc "Stéphane Miqueu" a écrit dans le message de news:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
-- Ami Calmant Stéphane
Bonjour,
manu a raison et tord.
raison car il est plus facile pour lui de le faire directement en acces
natif avec 1 requete.
maintenant je ne vois pas ce qui genrait de le faire en
SQLManagerX.j'utilise dans le data center une base pour gerer le treeview et
dans le chargment pas de probleme. dans ta desription sur le site
SQLManagerX tu parle de n° de requete donc tu passe par l'acces natif. sinon
SQLManagerX ouvre et ferme les requete a chaque fois donc pas de gene de ce
cote la. si on utilise SQLPremier et SQLSuivant, le N° de requete est
referme a chaque fois donc il serait possibile de le faire et le data center
le fais bien.
maintenant je pense qu'il faut plutot que tu t'oriente vers 1 requete et
parcours de cette requete sinon passe en SQLManagerX et faire des filtres
sur les tables et utiliser sauvePosition et retourPosition puisque tu
utilise la meme table ou sinon utiliser un autre objet sur la table
rien n'empeche d'instancier un objet SQLManagerX au moment ou tu en a
besoin.
bref tout depend aussi de comment est fait la table, et comme est stocké la
hierarchisation
deuxieme point a eviter : la recursivite
sous windev elle est limite. faites un test sur la multiplication chinoise
pour voir combien d'appel on peu avoir avant d'exploser la pile
voici a procedure :
FUNCTION multiplication(vA , vB)
SI vB > 0 ALORS RENVOYER(vA+multiplication(vA,vB-1)) SINON RENVOYER vB
et l'appel :
v_res est un entier
v_res = multiplication(1,842)
Trace(v_res)
en Windev 7.5 842 appels est le maximum si jamais vous mettez 843 ca plante
donc mef avec le recursif
bref il y a surement une solution maintenant voir quelle option tu veux
prendre
@+
donc
"Stéphane Miqueu" <stephane.miqueu@free.fr> a écrit dans le message de news:
mn.23db7d6439380cf2.49235@free.fr...
Bonjour,
Je rencontre un petit souci.
Soit une table de produits composés de Matières et/ou de Bases
Une base peut être composée de Matières et/ou de Bases
En gros :
P1
--B1
----M2
----M3
----M4
--M2
--M26
--M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique
que je sais faire. MAIS les données sont dans une base SQL et ma fonction
récursive se plante. A l'affichage je n'ai que :
P1
--B1
----M2
----M3
----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça
plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante
toujours.
manu a raison et tord. raison car il est plus facile pour lui de le faire directement en acces natif avec 1 requete.
maintenant je ne vois pas ce qui genrait de le faire en SQLManagerX.j'utilise dans le data center une base pour gerer le treeview et dans le chargment pas de probleme. dans ta desription sur le site SQLManagerX tu parle de n° de requete donc tu passe par l'acces natif. sinon SQLManagerX ouvre et ferme les requete a chaque fois donc pas de gene de ce cote la. si on utilise SQLPremier et SQLSuivant, le N° de requete est referme a chaque fois donc il serait possibile de le faire et le data center le fais bien.
maintenant je pense qu'il faut plutot que tu t'oriente vers 1 requete et parcours de cette requete sinon passe en SQLManagerX et faire des filtres sur les tables et utiliser sauvePosition et retourPosition puisque tu utilise la meme table ou sinon utiliser un autre objet sur la table
rien n'empeche d'instancier un objet SQLManagerX au moment ou tu en a besoin.
bref tout depend aussi de comment est fait la table, et comme est stocké la hierarchisation
deuxieme point a eviter : la recursivite sous windev elle est limite. faites un test sur la multiplication chinoise pour voir combien d'appel on peu avoir avant d'exploser la pile
voici a procedure : FUNCTION multiplication(vA , vB) SI vB > 0 ALORS RENVOYER(vA+multiplication(vA,vB-1)) SINON RENVOYER vB
et l'appel : v_res est un entier v_res = multiplication(1,842) Trace(v_res)
en Windev 7.5 842 appels est le maximum si jamais vous mettez 843 ca plante donc mef avec le recursif
bref il y a surement une solution maintenant voir quelle option tu veux prendre
@+
donc "Stéphane Miqueu" a écrit dans le message de news:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
-- Ami Calmant Stéphane
Stéphane Miqueu
Après mûre réflexion, Emmanuel Lecoester a écrit :
Comme répondu sur le forum du site (parce que si je dit la réponse est sur le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options : - requete avec auto-jointure(s) - utilisation de SQLManagerX qui possède les méthodes SauvePosition et RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes migrations de projet. Le fait de tout mettre dans une requete assure : un temps de réponse constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base de données (du moment que les indexes existent). Seule contrainte : si ta recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre (construction de ta requete), si elle possède une profondeur maxi, suffit de faire n+1 jointure :)
Voilà : à toi de faire ton choix :)
Bienvenue parmi nous "
++
Bonjour,
Ok j'arrive à suivre. Effectivement pour l'instant je ne passe que par l'accès natif (pas de SQLManagerX) en incrémentant le n° de requête mais ça ne fonctionne pas.
Donc soit je gère un tableau dynamique pour stocker le résultat de ma requête et je traite ce tableau soit j'essais la solution de Manu (requete avec auto-jointure(s)) mais ça je ne vois pas bien comment le faire.
Je m'en vais de ce pas chercher sur le net.
Merci de votre aide
-- Ami Calmant Stéphane
Après mûre réflexion, Emmanuel Lecoester a écrit :
Comme répondu sur le forum du site (parce que si je dit la réponse est sur
le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options :
- requete avec auto-jointure(s)
- utilisation de SQLManagerX qui possède les méthodes SauvePosition et
RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes
migrations de projet.
Le fait de tout mettre dans une requete assure : un temps de réponse
constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base
de données (du moment que les indexes existent). Seule contrainte : si ta
recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre
(construction de ta requete), si elle possède une profondeur maxi, suffit de
faire n+1 jointure :)
Voilà : à toi de faire ton choix :)
Bienvenue parmi nous
"
++
Bonjour,
Ok j'arrive à suivre. Effectivement pour l'instant je ne passe que par
l'accès natif (pas de SQLManagerX) en incrémentant le n° de requête
mais ça ne fonctionne pas.
Donc soit je gère un tableau dynamique pour stocker le résultat de ma
requête et je traite ce tableau soit j'essais la solution de Manu
(requete avec auto-jointure(s)) mais ça je ne vois pas bien comment le
faire.
Après mûre réflexion, Emmanuel Lecoester a écrit :
Comme répondu sur le forum du site (parce que si je dit la réponse est sur le forum du site c'est de la pub ;-))
"Bonjour Stéphane,
La récursivité peut être résolue avec 2 options : - requete avec auto-jointure(s) - utilisation de SQLManagerX qui possède les méthodes SauvePosition et RetourPosition du moment que la table possède une clé primaire
Maintenant j'ai toujours réussi à me passer de l'option 2 dans mes migrations de projet. Le fait de tout mettre dans une requete assure : un temps de réponse constant quelque soit le nombre d'utilisateurs, un accès optimisé à la base de données (du moment que les indexes existent). Seule contrainte : si ta recursivité n'a pas de fond maximum c'est plus compliqué à mettre en oeuvre (construction de ta requete), si elle possède une profondeur maxi, suffit de faire n+1 jointure :)
Voilà : à toi de faire ton choix :)
Bienvenue parmi nous "
++
Bonjour,
Ok j'arrive à suivre. Effectivement pour l'instant je ne passe que par l'accès natif (pas de SQLManagerX) en incrémentant le n° de requête mais ça ne fonctionne pas.
Donc soit je gère un tableau dynamique pour stocker le résultat de ma requête et je traite ce tableau soit j'essais la solution de Manu (requete avec auto-jointure(s)) mais ça je ne vois pas bien comment le faire.
Je m'en vais de ce pas chercher sur le net.
Merci de votre aide
-- Ami Calmant Stéphane
nwjb
Le Tue, 04 Apr 2006 16:27:03 +0200, Stéphane Miqueu a écrit:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
-- Ami Calmant Stéphane
J'utilise la même méthode en concaténant le niveau au nom de la requête et n'ai pas de problèmes spécial. J'utilise une base Oracle en accès OleDB depuis WD direct, mais fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le niveau le plus bas et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des 'Favoris'. La profondeur est habituellement assez limitée ( moins de 10 niveaux). Si le code est utile je peux le mettre.
-- J.Bratières
Le Tue, 04 Apr 2006 16:27:03 +0200, Stéphane Miqueu
<stephane.miqueu@free.fr> a écrit:
Bonjour,
Je rencontre un petit souci.
Soit une table de produits composés de Matières et/ou de Bases
Une base peut être composée de Matières et/ou de Bases
En gros :
P1
--B1
----M2
----M3
----M4
--M2
--M26
--M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du
classique que je sais faire. MAIS les données sont dans une base SQL et
ma fonction récursive se plante. A l'affichage je n'ai que :
P1
--B1
----M2
----M3
----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça
plante. Maintenant j'incrémente le n° à chaque appel récursif et ça
plante toujours.
Des idées ?
--
Ami Calmant
Stéphane
J'utilise la même méthode en concaténant le niveau au nom de la requête et
n'ai
pas de problèmes spécial. J'utilise une base Oracle en accès OleDB depuis
WD direct, mais
fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le
niveau le plus bas
et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des
'Favoris'. La profondeur
est habituellement assez limitée ( moins de 10 niveaux). Si le code est
utile je peux le mettre.
Le Tue, 04 Apr 2006 16:27:03 +0200, Stéphane Miqueu a écrit:
Bonjour,
Je rencontre un petit souci. Soit une table de produits composés de Matières et/ou de Bases Une base peut être composée de Matières et/ou de Bases En gros : P1 --B1 ----M2 ----M3 ----M4 --M2 --M26 --M75
Je voudrais faire afficher tout ça dans un treeview. Rien que du classique que je sais faire. MAIS les données sont dans une base SQL et ma fonction récursive se plante. A l'affichage je n'ai que : P1 --B1 ----M2 ----M3 ----M4
Au début j'utilisais toujours le même n° de requête donc normal que ça plante. Maintenant j'incrémente le n° à chaque appel récursif et ça plante toujours.
Des idées ?
-- Ami Calmant Stéphane
J'utilise la même méthode en concaténant le niveau au nom de la requête et n'ai pas de problèmes spécial. J'utilise une base Oracle en accès OleDB depuis WD direct, mais fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le niveau le plus bas et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des 'Favoris'. La profondeur est habituellement assez limitée ( moins de 10 niveaux). Si le code est utile je peux le mettre.
-- J.Bratières
Stéphane Miqueu
nwjb a écrit :
J'utilise la même méthode en concaténant le niveau au nom de la requête et n'ai pas de problèmes spécial. J'utilise une base Oracle en accès OleDB depuis WD direct, mais fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le niveau le plus bas et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des 'Favoris'. La profondeur est habituellement assez limitée ( moins de 10 niveaux). Si le code est utile je peux le mettre.
--J.Bratières
Un exemple de code est toujours utile pour s'enrichir.
Pour une gestion de Favoris, j'aurais plutôt adopté une structure 'nested tree' bien plus simple à gérer (1 seule table) et ainsi on s'évite la récursivité.
Dans mon cas c'est impossible car un élément de produits peut être composé d'un autre élément de produit qui lui même ...
-- Ami Calmant Stéphane
nwjb a écrit :
J'utilise la même méthode en concaténant le niveau au nom de la requête
et n'ai
pas de problèmes spécial. J'utilise une base Oracle en accès OleDB
depuis WD direct, mais
fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le
niveau le plus bas
et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des
'Favoris'. La profondeur
est habituellement assez limitée ( moins de 10 niveaux). Si le code est
utile je peux le mettre.
--J.Bratières
Un exemple de code est toujours utile pour s'enrichir.
Pour une gestion de Favoris, j'aurais plutôt adopté une structure
'nested tree' bien plus simple à gérer (1 seule table) et ainsi on
s'évite la récursivité.
Dans mon cas c'est impossible car un élément de produits peut être
composé d'un autre élément de produit qui lui même ...
J'utilise la même méthode en concaténant le niveau au nom de la requête et n'ai pas de problèmes spécial. J'utilise une base Oracle en accès OleDB depuis WD direct, mais fonctionne aussi sur fichiers HF. Il ne faut pas oublier de détecter le niveau le plus bas et de 'refermer' les niveaux ouverts. J'utilise cela pour gérer des 'Favoris'. La profondeur est habituellement assez limitée ( moins de 10 niveaux). Si le code est utile je peux le mettre.
--J.Bratières
Un exemple de code est toujours utile pour s'enrichir.
Pour une gestion de Favoris, j'aurais plutôt adopté une structure 'nested tree' bien plus simple à gérer (1 seule table) et ainsi on s'évite la récursivité.
Dans mon cas c'est impossible car un élément de produits peut être composé d'un autre élément de produit qui lui même ...
