Office: (Office 2000) Suche Beispiel für Treeview

nested set würde ich nur bei starren Zuordnungen anwenden. (einmal erstellt, nie wieder geändert)

Ich verwende z.B. ein Treeview zur Darstellung von Stücklisten (Baukasten-Stückliste mit n:m-Tabelle, welche die Parent/Child-Beziehung liefert.)
Dabei nutze ich je nach Darstellungsvariante eine Hilfstabelle mit der in eine Struktur-StueLi umgeformten Baukasten-StüLi, wenn alle Bauteile auf einmal in das Treeview eingelesen und dargestellt werden sollen. (rekursives Einlesen ist bei größeren Datenmengen langsam, daher der Umweg über die Hilfstabelle und "ebenenweises" Einlesen)
Als zweiter Variante lese ich die Bauteile der einzelnen Baugruppen erst beim "Aufklappen" eines Astes ein (wie beim rekursiven Einlesen). Das ist schneller, wenn der Anwender nur einzelne Strukturen der Gesamtstückliste sehen will, da immer nur die jeweils gewünschte Baugruppe ins Treeview übertragen wird.


In deinem Fall wird es vermutlich keine der oben erwähnten Varianten ein Laufzeitproblem ergeben, da so eine "Auftragsstruktur" nicht aus mehreren hundert Elementen bestehen wird. *wink.gif*

 

Hallo Josef P,

danke für den Hinweis. Dann weiss ich schon mal, das ich mich mit nested Set nicht weiter beschäftigen muss.
In der Tat können in meinem Fall Angebote/Rechnungen im Max-Fall
200 Einträge haben. Ich rechne mal mit max 150 echten Positionen und der Rest sind Textpositionen und Gliederungspositionen usw.
Ab welcher Anzahl wird es deiner Meinung nach zu zähflüssig?
Wie wirkt sich ein SQL-Server im Gegensatz zu ACCESS als Backend aus??

Das teilweise Aufklappen von Baumzweigen würd ich auch umsetzen wollen.

Gruß Thomas

 

Das kann ich nicht mit einer Zahl beantworten, da die Laufzeit bei Komplettdarstellung von der Anzahl der Gliederungselemente abhängen wird.
Und wenn du immer nur einzelne Äste aufklappst, ist auch diese Anzahl egal.

Wenn die Fähigkeiten des SQL-Servers ausgenutzt werden, hast du mit einem Jet-BE keine Chance die Auswertungsgeschwindigkeit zu erreichen.
Nur die Tabellen in eine SQL-Server-Datenbank zu verlagern kann eine Beschleunigung aber auch eine Verlangsamung bringen.
Ich verwende kein Jet-BE für Produktivsysteme sondern nur aktive DBMS wie den SQL-Server. Der Grund liegt aber gar nicht so sehr an der Geschwindigkeit sondern vielmehr an der Zugriffssicherheit und der Datensicherheit (Ausfallssicherheit, Backup/Restore)

 

Hallo Thomas,

die Parent-Child-Mechanik dürfte für "unsere" *Smilie Anforderungen ausreichen. Nested Sets ist gut für starre Strukturen, die selten verändert und oft gelesen werden. Mit 200 Positionen, die in 2-3 Ebenen verschachtelt sind, habe ich getestet, geht problemlos und ohne große Verzögerung mit "totalem Drilldown", also ohne Nachladen. Spaßhalber habe ich mal 2000 Positionen darstellen lassen, das dauert dann ein paar Sekunden. Aber 2000 Positionen sind unrealistisch in der fraglichen Firma.

Der SQL-Server alleine (kenne aber nur den 2000er) kann auch nicht besser mit Parent-Child-Tabellen umgehen. Seine Erweiterung, die Analysis Services, können hingegen solche Hierarchien darstellen. Im Betrieb nutzen wir z.B. diese Technik, um einen Kontenplan aufzusummieren. Allerdings werden die Ergebnisse dann in einer besonderen Abfragesprache, MDX, geschrieben. Und die ist heftig, sie hat mit SQL nur enfernte Ähnlichkeit. Im Prinzip wird das, was Excel mit den Pivottables (und deren Feinheiten wie berechnete Elemente und Felder) in Textform nachgebildet. Dafür geht das dann sauschnell, weil (bestenfalls) alle Permutationen der Dimensionen vorherberechnet sind. Summen werden also nicht on the fly berechnet, sondern lediglich "abgerufen". Wenn man es denn kann.

Bei dir wird es aber weniger um solche hierarchische Pläne gehen. Summen pro Gliederungsebene (Haus 1) berechne ich in meinem Programm problemlos über rekursive Methoden.

Die Performance gewinnt enorm, wenn die Indizes stimmen.

Die Spaltung in mehrere Tabellen (Los, Gewerk, Titel, Position) halte ich für sinnlos, da zu starr. Die Ebenen sollten nicht begrenzt sein. Und ob man die Parents in der gleichen oder einer 1:1-Tabelle ablegt, ist Geschmackssache.

Gruß
Martin

 

Anbei einmal eine kleines Beispiel um das rekursive und "ebenenweise" Auslesen einer Struktur zu vergleichen.
Anm.: im Beispiel wird zwar kein Treeview befüllt, das Prinzip sollte aber relativ einfach für das Befüllen eines Treeviews abgeändert werden können.

 

Ich ergänzte das zuvor gezeigtem Beispiel um das Befüllen eines Treeviews und testet mit dem Treeview die verschiedenen Varianten. (rekursiv vs. ebenenweise)

Ergebnis bei 722 Elementen der aufgelösten Struktur, die sich aus 661 "Baugruppen-Elementen" ergeben:
rekursiv: 500 ms
ebenweise: 70 ms
und als Alternative bei NodeClick nur die untergeordneten Element des ausgewählten Eintrags ermitteln: 1 ms pro Klick

Beispiel: http://access.joposol.com/download/S...rAufloesen.zip

 

Hallo Martin(Atrus2711),

danke für deine Unterstützung.

Damit ist klar das es ohne nested geht. Angebote mit sovielen Positionen
gehen in den Bereich Bücher.

Das wird bei mir auch ein Thema. Nach Änderung Positionen(Menge,Preis)
eine Neuberechnung Titel und Abschnittssummen.

Ok, also mindestens auf ID und ParentId.

War so nicht angedacht, (Los, Gewerk, Titel, Position) in eine Tabelle,
Texte wie allgemeine Hinweistexte und Kommentare in eine zweite Tabelle.
Dritte Tabelle für Hierachie. Aber egal, werde alles in eine packen.

Dank dir noch mal und ich denke, ich werd mich bei der Umsetzung noch mal bei dir melden, wenn das für dich ok ist?

Gruß Thomas

 

Hallo Josef P.,

vielen Dank für die, mit einem eindrucksvollen Beispiel unterlegten, Entscheidungshilfe.

Ich denke ebenenweise ist für mich der beste Kompromiss bei meinem Problem.

Wie gesagt, wenn man solche ausgezeichnete Entscheidungshilfe vor Augen geführt bekommt, ist die Auswahl leicht.

Einen besonders freundlichen Gruß nach A
Thomas

 

Wichtig war mir vor allem zu zeigen, dass ein rekursives Erstellen der Struktur keine Chance gegen "Datenverarbeitungstechnik" hat. Ich bin nämlich der Meinung, das viel zu oft rekursiv gearbeitet wird, obwohl Access eine Entwicklungsumgebung für Datenbankanwendungen ist. *wink.gif*

Die Alternative mit dem Ermitteln der Baugruppen bei NodeClick hat in meinem Beispiel noch einen Schönheitsfehler. Das [+] kommt erst wenn die untergeordneten Elemente eingelesen werden. Damit der User erkennt, dass es noch eine weitere Struktur unter noch nicht "angeklickten" Elementen gibt, sollte man sich aber etwas einfallen lassen. (Bei Stücklisten helfe ich mir mit Symbolen für Bautruppen und Einzelteilen)
Eine andere Möglichkeit wäre, bei NodeClick nicht die nächste sondern immer die übernächsten Elemente einzulesen.

Andererseits: wenn du wie in meinem Beispiel nicht mehr als 700 Strukturelemente hast, kann man sich die Zeit von 70ms "leisten" - auch wenn vielleicht aus den 70 ms bei einem BE im Netz 140 ms werden würden (was aber vermtulich nicht einmal sein wird), ist das einmalige Einlesen bestimmt so durchzuführen, dass der User davon nichts merkt. *wink.gif*

 

Hallo Josef und Martin,

Frage an die Tree-Meister.
Wenn ich in der linken Formularhälfte den Tree habe und in der Rechten ein
Unterformular zu Eingabe von Daten, wie verknüpfe ich selektierten Treenode mit dem Unterformular rechts?????


Beispiel: Links stehe ich auf einem Titel
01.01. Malerarbeiten
im Unterformular rechts erscheint
"Ordnungszahl :01.01."
"Text: Malerarbeiten"

Ich hoffe es ist verständlich ausgedrückt

Gruß Thomas

 

Ich speicher meistens im Tag eines Node-Element die ID.

Bei NodeClick könntest du da dann den Wert vom Node-Tag nehmen und ein ungebundenes Textfeld damit füllen, welches wiederum als Verknüpfungseigenschaft für ein UF dient.

Eine etwas elegantere Variante: ich fülle kein Textfeld sondern eine selbst erstellte Form-Property und erledige in dieser die notwendigen Schritte wie ID an eine Methode der abhängigen UF weiterrreichen usw. (Diese Variante ist etwas flüssiger im Ablauf als das einfache Verknüpfen des UF per Textfeld im HF.)

 

Hallo,

@tr-si:
In meinem Formular sitz der Tree ebenfalls links, die Anzeigefelder aber direkt im gleichen Form daneben (kein Ufo). Die Nodes haben die ID des dahinterstehenden Satzes als Key. Beim NodeClick wird (derzeit) die Recordsource des Formulars so eingestellt, dass nur der Node-Satz gezeigt wird.

Etwa so:
Me.Recordsource = "SELECT .. FROM Tabelle WHERE ID = " & Mid$(Node.Key,2)

Bei dir müsste das mit einem Ufo analog gehen, dann halt Me.frmUfo.Form.Recordsource = ...

Diese Ladefunktion habe ich in eine Formmethode gepackt, die noch ein paar andere Dinge erledigt. Aber das wesentliche ist die Anzeige des "richtigen" Satzes.

Das ermöglicht mir, mit gebundenen Formularen zu arbeiten. Da die Nodekeys mit einem Buchstaben beginnen müssen (bei mir ein a), wird dieser in der Where-Klausel abgeschnitten.

Auf diese Tour bleibt die Tag-property frei für andere Sachen, z.B. für Zeilen-Objekte, was den Weg für ein objektorientiertes, ungebundenes Arbeiten frei machen würde. Aber das mache ich in Zukunft, und zwar nicht mehr mit Access (.NET).

Bild anbei (die AUflösung ist ein bisschen verschubbert, wird noch glattgezogen. Die violetten Controls kommen noch weg, die sind nur für Entwicklungszwecke).

Gruß
Martin

 

Hallo Martin,


das Beispiel ist nachvollziehbar.

Danke dafür.

Verstehe ich das richtig, du steigst von ACCESS auf .Net um? Oder packst du .Net Teile in ACCESS rein, soll wohl nicht gehen hab ich gehört.

Andere Frage(n)
Was verbirgt sich in der Grafik hinter den Button Rauf/Runter??
Ich denke mal ein verschieben eines Nodes im Baum. Aber wo merkst du dir die Position, da Linker und rechter Nachbar nicht gespeichert werden???

01. Renovierung
01.01. Malerarbeiten
01.01.001 Untergrund herrichten
01.01.002 Tapete streichen
01.01.003 Tapezieren

002 müsste hinter 003, wie machst du das??

Was verbirgt sich hinter Kopie von.....? Ich denke mal ein einfügen aus anderen Angeboten/Musterangeboten/Jumbos???? Frage wie?

Gruß Thomas

 

.Net ist meine nächste Baustelle. Momentan hab ich mit meinem Bauabrechnungsprogramm genug zu tun :-) und das bleibt erstmal ganz in Access. Wenn ich mal viiiiiel Zeit habe, schreib ich das vielleicht in .Net nach. Ich kenns aber bisher kaum.

Die Rauf-Runter-Buttons verschieben den Node um eins nach oben oder unten. Ein linker und rechter Nachbar wird nicht gespsichert, das gibts auch nur in nested Sets. Da das ein Tausch mit dem Brudernode vorher bzw. nachher ist, muss ich nur den .Next bzw. Previous an meine segensreiche UpdateSorter-Sub übergeben, die den Nodexindex in das Sorterfeld schreibt. Neben der Parent-Angabe habe ich eben auch einen Sorter in der Tabelle, der zu jeder Zeit den Node.Index in der Tabelle nachzieht. Wenn ich Äste per Drag und Drop umschiebe, dann steht die präzise Tauschordnung nicht fest; dann wird jede Zeile in ihrem Sorterfeld auf den Nodeindex gesetzt.

Auch der Kopie-Von-Button macht, was du erwartest (hab ich das Programm für dich geschrieben? *grins ). Man wählt ein Quelldokument aus, und dessen zeilen werden dann kopiert. Die Zeilen werden in eine Temporäre Tabelle (gelle, Josef P. *wink.gif* ) geschrieben, erhalten dort die neuen IDs, werden von dort in das Zieldokument übertragen. Der Sorter ist dabei einfach der Ursprungssorter + [Nodeindex der Ziel-Zeile]. Sprich: wenn ich einen Teilbaum von 5 Sätzen (Sorter 1-5) im Zielbaum unterhalb der 6. Stelle ansetze, werden das die Positionen (6+1) bis (6+1+5).

 

Hallo Thomas,

wieso verwendest du nicht Drag&Drop für das verschieben der Positionen??