Office: (Office 2010) TreeView

Hallo,
ich möchte gern eine Stücklistenauflösung mit einem TV realisieren, welcher in unbekannter Tiefe verschachtelt sein kann.
Als Key nehme ich dafür die Artikelnummer her, den ich dann an den SubKey weitergebe.
Prinzipiell funktioniert es, aber das Problem ist, dass es bei Artikeln, welche mehrfach vorkommen (z.B. Schrauben o.ä., welche die selbe Artikelnummer haben), logischerweise zu einer UniqueKey-Verletzung kommt.
Eine eindeutige ID ist zwar vorhanden, aber ich bekomm es nicht gebacken, die mit einzubauen.
Ich bin schon am Verzweifeln. *weinen

Könnte mir denn evtl. jemand auf die Sprünge helfen?

Anbei ein Codeausschnitt:
Code:

Der Aufruf erfolgt hiermit:

Code:

Viele Grüße,
Volker

:)

 

... ich durchschaue zwar Deinen Algorithmus zum Füllen des TV nicht, aber Du hast Dir die Frage praktisch selbst beantwortet. Wenn es zu verschiedenen Eltern gleiche Kinder geben kann, dann muss Du dem Schlüssel der Kinder den Schlüssel der Eltern voranstellen, sprich: der Schlüssel eines Kindelementes ergibt sich aus dem Schlüssel seines Elternelementes und seinem eigenen Schlüssel...

 

Hallo,
danke für deine Hilfe.

Ja, du hast recht, ich muss den Key irgendwie eindeutig gestalten.
Aber nur wie??

Mit zwei Ebenen haut es auch hin. Aber so bald in der dritten Ebene (also das Enkelkind *wink.gif* ) zwei mal auftaucht, haut es nicht mehr hin.
Da kommt dann "Key not found".

Im Anhang habe ich mal ein Scrreenshot der Struktur.
Das blau markierte wäre in diesem Fall so eine Wiederholung.
Beim Artikel 921.11.02 müsste der wieder auftauchen.

Ich denk, ich sehe den Wald vor lauer Bäumen nicht mehr.

Ich bin für Vorschläge gerne zu haben, da kannst du mir glauben.

 

... wie gesagt, ich durchschaue Deinen Algorithmus nicht, aber es ist so, dass der Schlüssel eines Knoten den gesamten Pfad (angefangen vom Wurzelknoten) wiedergeben muss.
Wie sieht denn die Datengrundlage aus?

 

Hallo,
ich hab mal zur Demonstration eine Test-DB angehängt.

Zur Veranschaulichung ist der Artikel 921.00.01, bzw. 921.04.12 optimal.

Wie bereits im vorigen Post geschrieben, bin ich für einen Vorschlag, wie man den TV besser füllt, sehr dankbar.

Ich hab mich da an den Vorschlag aus André Minhorsts Buch "Access 2010" auf Seit 313 angelehnt.

Danke für deine Hilfe.

 

... beteiligt sind offenbar die Tabellen "Artikel" und "Material" und die Felder "WCORAROV" und "ARTNR"?
In welcher Beziehung stehen diese Tabellen zueinander?
Wo und wie findet eine Rekursion statt?

 

Eigentlich wird nur die Tabelle Material benötigt. Die Tabelle Artikel benötige ich nur um die Artikelbezeichnungen auszulesen, welche ich aber hier aus Datenschutzgründen nicht mit veröffentlichen wollte, kann also vernachlässigt werden.
In der Abfrage vergaß ich diese zu entfernen.

Die Tabellen habe ich aus einer Oracle-DB importiert, deswegen sind keine Schlüssel angelegt. Die Tabellen stehen über die ARTNR in Beziehung. Die Spalte WCORAROWID enthält einen eindeutigen Wert, soweit ich weiß müsste es sich um einen Autoincrementwert handeln, bin mir aber nicht sicher.
Das Feld STLAPLNR spiegelt praktisch das fertige Bauteil wieder, in der Spalte ARTNR stehen die ensprechenden Unterteile drin.

Also so in etwa:
Code:

Meinst du die Rekursion zum Befüllen des TVs ?
Code:

[EDIT]
Ich vergaß zu erwähnen, dass natürlich auch ein "Child-Teil" auch wieder "Child-Teile" besitzen kann, usw. (siehe Codetabelle).

 

... und wie kommt dann die "unbekannte Tiefe" zustande?
in Deinem Beispiel sehe ich folgende Hierachie: Code:

inwieweit können sich jetzt weitere Tiefen ergeben?

 

Sorry,
hab eben meinen vorigen Artikel geändert um das noch darzustellen:
Ein Child-Teil kann auch wieder Child-Teile enthalten, usw.
Ich sollte vielleicht von Baugruppen sprechen, die wiederum Baugruppen aus Einzelteilen enthalten können.
Hab mich etwas verdrückt ausgekehrt. *redface

 

... d. h., eine ARTNR kann auch wieder als STLAPLNR fungieren? Und ARTNR, die nicht in STLAPLNR auftauchen sind "echte" Kinder (Blätter)?

 

Genau!

 

Wobei die Tiefe eigentlich keine Rolle spielt. das funktioniert ja alles bestens. Aber eben nur so lange, bis ein Child das zweite mal auftaucht.
Wenn ich jetzt die ParentID mit übergebe (in welcher Form auch immer), dann passt nach dem Rücksprung aus dem Unterzweig der Bezug zum übergeordneten Zweig nicht mehr, da ja mittlerweile die ParentID durch einen anderen Wert überschrieben wurde. Irgendwie beißt sich die Katz in den eigenen Schwanz.
Irgendwie müsste die ParentID gepuffert werden, um dann bei Bedarf wieder herstellen zu können. Aber ich weiß eben nicht wie. Oder hab ich da ein prinzipielles Verständnisproblem?? *eek.gif*

Ansonsten muss eben alles in einer Ebene ausgegeben werden. Ist zwar unübersichtlich, aber was solls.

 

... also ich würde das spontan rekursiv programmieren, in etwa so (Achtung, Luft-Code!): Code:

...

 

Hallo Volker,
du kannst der nächsten Ebene den Parent-Key z.B. durch einen geänderten Aufruf der Prozedur mitgeben:
Code:

wobei ByVal dafür sorgt, dass sich der Key in der höheren Ebene nicht verändert.

Auf der Root-Ebene bleibt der Parameter leer, was du mit IsMissing verarbeiten kannst.

 

Hallo,
erst einmal herzlichen Dank euch beiden für die Unterstützung.

@FW:
Das passt!
Ich habe lediglich nur den Loop aus der ersten Schleife entfernt, da ich immer nur einen ausgewählten Artikel auflösen möchte. Ansonsten ist´s *top

@Marsu:
Wenn die ParentID als Long-Wert deklariere wird ist diese doch nie leer? Mit Variant hat es funktioniert. Aber ich bekomme es trotzdem nicht gebacken. Egal wie, wo und wann ich den übergebe und setze, entweder "Element not found", oder "Key is not unique".
Ich bin wahrscheinlich zu doof um das zu kapieren, ich schieb es einfach mal auf das Alter. *stupid