Hallo,
bei einem kleinen Projekt versuche ich mit Access Daten aus einem anderen Programm zu importieren und mit Hilfe von Berichten so aufzuteilen und zu strukturieren, dass man sie übersichtlicher, einfacher und schneller bearbeiten kann. Am Ende wird dann alles wieder in das Ursprungsprogramm zurückgespielt.
In dem Quell- oder Datenerzeugungsprogramm sind einige Objekte, wie in einer Baumstruktur, anderen untergeordnet. Beim Exportieren bekomme ich aber alle Objekte als einzelne Datensätze nacheinander aufgelistet, leider entspricht die Reihenfolge der Auflistung zufällig nicht der Datenstruktur.
Da die Exportschnittstelle sehr gut dokumentiert und flexibel ist, kann ich die ID des übergeordneten Objektes mit auslesen, ich erhalte also ID und die zugehörige ParentID jeweils als eigenes Attribut.
Mein Ziel ist es, mittels Abfragen und Berichten die Datensätze als folgende (Baum-)Struktur auszugeben:
(Beispiel)
1. Objekt1
1.1 Objekt, das Objekt 1 als Parent hat
1.1.2 Objekt, das Objekt 1.1 als Parent hat
...
1.2 Objekt, das Objekt 1 als Parent hat
1.2.1 Objekt, das Objekt 1.1 als Parent hat
...
usw.
Ich habe schon einiges ausprobiert, aber mehr als zwei Ebenen habe ich nie geschafft.
Hatte von Euch schon mal jemand ein solches Problem, oder schon mal gemacht?
Gruß Sparky
Hallo,
für konkrete Hilfestellungen werden konkrete Informationen benötigt.
Derartige Angaben wie
Zitateinige Objekte
Zitatwie in einer Baumstruktur
Zitatanderen untergeordnet
sind wenig hilfreich.
Zitat von: MaggieMay am Juni 11, 2015, 23:04:52
Hallo,
für konkrete Hilfestellungen werden konkrete Informationen benötigt.
Derartige Angaben wie
Zitateinige Objekte
Zitatwie in einer Baumstruktur
Zitatanderen untergeordnet
sind wenig hilfreich.
Ok, war vielleicht zu abstrakt:
Es handelt sich um Bauteile von Gebäuden.
So gibt es zum Beispiel Wände, die Öffnungen für Fenster und Türen enthalten. In diesen Öffnungen sind dann die jeweiligen Fenster und Türen.
Wenn ich das ganze auslese, dann bekomme ich alle Wände, Öffnungen, Fenster und Türen als einzelne Datensätze in unsortierter Reihenfolge.
Ich möchte sie gerne in eine übersichtliche Reihenfolge bringen:
1. Wand1
2. Fensteröffnung1 in Wand1
3. Fenster in Fensteröffnung1
4. Türöffnung1 in Wand1
5. Tür in Türöffnung1
6. Fensteröffnung2 in Wand1
7. Fenster in Fensteröffnung2
8. Wand2
9. Wand3
10. Fensteröffnung in Wand3
usw.
Jedes untergeordnete Objekt (Öffnung, Tür oder Fenster) kennt nur sein direkt übergeordentes Objekt (Wand oder Öffnung).
Wenn man es programieren wollte, würde man wie folgt vorgehen:
Mann nimmt die ID eines Objektes, dass keine ParentID hat (Wand).
Dannach durchsucht man alle Objekte, ob die ID des ersten Objektes als ParentID vorhanden ist (Öffnungen).
Wenn Ja,
wird die ÖffnungsID in die nächste Spalte geschrieben und dann wiederum
alle Objekte durchsucht, ob sie denn die ÖffnungsID als ParentID haben (Fenster und Türen)
Wenn Ja, ID in die nächste Zeile und nach nächstes Objekt (Fenster und Tür) suchen.
Wenn Nein, weitere Objekte (Öffnungen) suchen usw.
Wenn nein, nächste Wand usw.
Ich habe bisher keine Lösung gefunden, diese verschachtelten Schleifen mit Access Abfragen umzusetzten.
Wenn ich eine Abfrage/Tabelle mit den ID in der o.g. Reihenfolge habe, ist der Rest dann ganz einfach umzusetzten.
Gruß Sparky
Zitat von: sparky_Ol am Juni 12, 2015, 00:42:27Ich habe bisher keine Lösung gefunden, diese verschachtelten Schleifen mit Access Abfragen umzusetzten.
Wenn ich eine Abfrage/Tabelle mit den ID in der o.g. Reihenfolge habe, ist der Rest dann ganz einfach umzusetzten.
Das, was Du beschreibst, ist programmiertechnisch recht leicht umzusetzen, indem Du rekursiv entweder von der Wurzel oder vom Blatt her durchgehst (Baumtraversierung, 1.+2. Semester Informatik).
Ob es im Access-SQL geht, bin ich mir nicht sicher, denke eher nicht. Du kannst mal googeln mit "hierarchische Abfrage SQL Access" o.ä. Und soweit ich weiß können Access-Berichte auch keine variable Tiefe haben. Ich würde mir überlegen, ob Access hier wirklich gut geeignet ist.
Hi,
das Stichwort "Stückliste" könnte evtl. hilfreich bei der Suche nach Lösungsansätzen sein, oder auch "Bauteile".
Es wird jedenfalls auf eine rekursiv aufzurufende Funktion hinauslaufen, die u.U. auch in Verbindung mit einer Abfrage eingesetzt werden könnte.
PS:
ZitatUnd soweit ich weiß können Access-Berichte auch keine variable Tiefe haben.
Was genau meinst du damit?
Ich stelle mir das so vor, dass man den Bauteilen im Zuge ihrer Ermittlung eine lfd. Nummer zuordnet, nach der man dann im Bericht sortieren kann.
Zitat von: MaggieMay am Juni 12, 2015, 12:55:36
Ich stelle mir das so vor, dass man den Bauteilen im Zuge ihrer Ermittlung eine lfd. Nummer zuordnet, nach der man dann im Bericht sortieren kann.
Er wollte eine Baumstruktur und keine sortierte Liste.
Zitat von: Wurliwurm am Juni 12, 2015, 13:29:14
Zitat von: MaggieMay am Juni 12, 2015, 12:55:36
Ich stelle mir das so vor, dass man den Bauteilen im Zuge ihrer Ermittlung eine lfd. Nummer zuordnet, nach der man dann im Bericht sortieren kann.
Er wollte eine Baumstruktur und keine sortierte Liste.
Wenn die Liste wie eine aufgeklappte Baumstruktur sortiert ist, wäre alles Gut.
Es geht darum die Öffnungen und Bauteile im Bericht den zugehörigen Wänden zuzuordnen, um eine bessere Gesamtübersicht zu erhalten. Man muss dann nicht durch die einzelnen Seiten blättern, um zu erfahren ob und welche Fenster denn in der Wand sind und wie groß die zugehörigen Öffnungen sind.
Gruß Sparky
Zitat von: Wurliwurm am Juni 12, 2015, 13:29:14Er wollte eine Baumstruktur und keine sortierte Liste.
Das hier ist für mich keine Baumstruktur:
ZitatIch möchte sie gerne in eine übersichtliche Reihenfolge bringen:
1. Wand1
2. Fensteröffnung1 in Wand1
3. Fenster in Fensteröffnung1
4. Türöffnung1 in Wand1
Allerdings dürfte es letztendlich noch die einfachste Übung sein, ein Treeview aus den Bauteilen zu erstellen, weil die Bauteile dabei automatisch den übergeordneten Knoten zugeordnet werden.
@Sparky:
Zeig doch mal ein Beispiel, damit man sieht wie der Export-Datensatz aufgebaut ist.
Zitat von: MaggieMay am Juni 12, 2015, 14:15:27
@Sparky:
Zeig doch mal ein Beispiel, damit man sieht wie der Export-Datensatz aufgebaut ist.
Ich habe Euch in der Anlage mal eine auf die wichtigen Attribute bereinigte Export-Datei (Text-Tabstopp getrennt) hochgeladen.
Zur Erklärung:
A_Bauteil_ID: Interne ID des CAD-Programms (Text), wird nur einmal vergeben, keine Dublikate
Parent_A_Bauteil_ID: ID des übergeordneten Objektes (Text)
Geschoss_ID: ID des Geschosses (Zahl), 0 für Erdgeschoss, 1 für 1.OG, usw.
Objekt_ID: Interne ID des Objektes (Zahl)
Objektname: Objekt_ID als Text aufgelöst (Text)
Ich füge dann beim Einlesen in meine tbl_MasterObjekt noch eine ID (Auto-Wert) hinzu.
Zum sachlichen Verständniss, sollte ich vielleicht noch erklären, dass das CAD-Programm bei mehrteiligen Bauteilen einen übergeordneten Container als Gesamtobjekt (Gesamtwand, Gesamttüröffnung, ...) einfügt. In diesem sind keine Attribute vorhanden (könnt Ihr nicht sehen, da ich die Attribute nicht ausgegeben habe), es wird aber für die Sortierung in der Baumstruktur benötigt.
Ziel ist es, mit einer Sortierfunktion, oder SQL-Abfrage, die tbl_Master_Objekt in die entsprechende Reihenfolge (s.o.) zu bringen. Das würde am besten direkt beim Einlesen/Erstellen funktionieren.
Bisher wird das ganze mit einer Anfüge-Abfrage gelöst, die die Atrribute entsprechend zuweist.
Gruß Sparky
Ich habe Dir mal eine mdb gebaut, welche rekursiv von der Wurzel aus die Tabelle durchgeht und das Ganze in eine Textdatei ausgibt. Einfach auf dem Button in dem Formular klicken. Siehe Attachment
Zitat von: Wurliwurm am Juni 17, 2015, 13:45:42
Ich habe Dir mal eine mdb gebaut, welche rekursiv von der Wurzel aus die Tabelle durchgeht und das Ganze in eine Textdatei ausgibt. Einfach auf dem Button in dem Formular klicken. Siehe Attachment
Cool, Danke schön!
Das werde ich mir mal genauer anschauen, dann habe ich bestimmt noch einige Fragen dazu.
Gruß Sparky
Hallo,
ich hatte grade kurz zehn Minuten, um kurz draufzuschauen. Ich habe noch einen Fehler in der Importdatei entdeckt, dort wurden Räume sich selbst als Parent zugeordnet und konnten somit auch nicht von der Sortierfunktion erkannt werden. Nachdem ich das korrigiert habe, ist in der Textdatei auch alles so, wie ich es gewünscht hatte. Dabei habe ich noch ein par interessante Dinge herrausgefunden, die mir nachher noch Kopfzerbrechen bereiten werden, aber das hat hier erstmal nichts mit zu tun.
Wie ihr sicher gemerkt habe, bin ich kein ITler oder Programmierer, sondern Ingenieur mit einem besonderen Draht zu Software. Da ich im Studium auch Programmiersprachen gelernt habe (Java und C++) ist mir der allgemeine Syntax von VB(A) wohl geläufig, um kurz auszudrücken: Ich verstehe die Sprache, wenn ich sie lese, aber sprechen kann ich sie (noch) nicht.
Aus diesem Grund führe ich mein Projekt auch erstmal "händisch" mit Access durch, d.h. ich hangel mich von Hand von der Importdatei bis zur Ausgabedatei. Mir geht es erstmal darum die Machbarkeit an sich und die Umsetzbarkeit im speziellen mit ein par Kollegen zu testen. Wenns klappt, schauen wir weiter.
Ich werde mich gleich mal hinsetzen und nachvolziehen, was Du da schönes programmiert hast und schauen, wie ich das verwenden kann.
Gruß Sparky
Hallo Wurliwurm,
ich kämpfe mich grade durch Deinen Code "Hirachie", wenn ich das richtig verstanden habe dann
1. Öffnest Du alle Datensätze aus der Tabelle "Hierachie", die keine ParentIDs haben, also alle Stämme, und sortierst sie nach der A_Bauteil_ID.
Frage: Du hast sql als string definiert, d.h. es stehen jetzt alle kompletten Datensätze als ein Text hintereinander, oder wie sieht sql zu diesem Zeitpunkt aus?
2. Du öffnest das recordset rs und übergibst die sortierten Datensätze (sql).
Frage: das recordset (Tabelle) enthält jetzt alle kompletten Datensätze von 1., also alle ohne ParentIDs?
3. Du erzeugst einen Text strListe, der in einer Schleife immer weitergeschrieben wird:
Du nimmst einen Datensatz aus rs, schreibst den Objektnamen und die A_Bauteil_ID auf und springst in die nächste Zeile.
Dann rufst Du die Funktion AuflistenKinder mit der Übergabe der A_Bauteil_ID als strparent, dem Wert 1 als intTiefe und dem Text strListe als strListe.
Die Funktion AuflistenKinder macht folgendes:
4. Du definierst du einen Präfix, um die untergeordneten Einträge einzurücken.
5. Du fragst ab, ob ein Blatt (ohne ParentID) übergeben wird, wenn ja, werden alle Datensätze ohne ParentID in sql geschrieben, wenn nein, werden alle Datensätze, die strParent als ParentID haben in sql geschrieben. Dannach wird sql sortiert.
6. Du öffnest das recordset rs und übergibst die sortierten Datensätze (sql)
Frage: Dabei handelt es sich aber nicht um das rs aus HirachieAuflisten, da du es jeweils nur lokal definiert hast, oder?
7. Du erzeugst eine Schleife über alle Datensätze aus rs und schreibst den Text strListe weiter mit dem ersten "Kind", dann springst du in die nächste Zeile.
8. Du rufst die Funktion AuflistenKinder für das Kind auf und behandelst so alle Kindeskinder usw.
Frage: Wenn es Kindeskinder gibt, wird der Text weiter eingerückt und dort dort die Kindeskinder eingetragen, usw. Wenn es keine Kindeskinder gibt, dann wird das Weiterschreiben nicht ausgeführt, da in einer leeren Tabelle rs.EOF sofort erreicht ist, oder?
9. Wenn beide Schleifen durchlaufen sind (rs.EOF jeweils erreicht), dann werden die recordsets jeweils geschlossen und gelöscht.
10. Du erzeugst eine MsgBox und eine Textdatei in der Du den, mittlerweile aus viele Zeilen bestehenden strListe, ausgibst.
Das habe ich mitlerweile verstanden. :D
Wenn man jetzt aus meiner Importtabelle tblImport , in der die Importdatei eingelesen ist (bei Dir Hierachie), mit Deinen Funktionen eine neue tblImportSort machen will, dann müßte man anstatt einer Textdatei eine neue Tabelle erzeugen?
Dazu könnte man ein neues recordset rsSort nehmen, müsste es aber im Modul definieren, damit sowohl HierarchieAuflisten als auch AuflistenKinder da reinschreiben können, richtig?
Anstelle die strListe weiterzuschreiben würde jeweils ein neuer Datensatz mit der aktuellen A_Bauteil_ID und allen weiteren Attributen erzeugt werden.
Am Ende würde man aus dem recordset dann eine Tabelle tblImportSort machen.
Ist das vom Ansatz richtig gedacht?
Gruß Sparky
Zitat von: sparky_Ol am Juni 17, 2015, 22:43:19
Frage: Du hast sql als string definiert, d.h. es stehen jetzt alle kompletten Datensätze als ein Text hintereinander, oder wie sieht sql zu diesem Zeitpunkt aus?
Nein, der SQL-String ist dazu da, die SQL-Abfrage, welcher ja ein Text mit bestimmten syntaktischen Anforderungen (SELECT ... FROM ... WHERE ...) ist, zu speichern. Ist ein Hilfsvariable.
Zitat
Frage: das recordset (Tabelle) enthält jetzt alle kompletten Datensätze von 1., also alle ohne ParentIDs?
Es werden alle Datensätze ohne Parent, also die Wurzeln abgefragt, ja.
Zitat
Dann rufst Du die Funktion AuflistenKinder mit der Übergabe der A_Bauteil_ID als strparent, dem Wert 1 als intTiefe und dem Text strListe als strListe.
Ja. Die AuflistenKinder-Funktion erhält den Key der Mutter als Wertübergabe, die Tiefe als Zahl (wird nur für die Einrückungen gebraucht), und strListe als Referenzübergabe. strListe könnte auch eine globale Variable sein im ganzen Modul, würde im Prinzip nichts ändern.
Zitat
5. Du fragst ab, ob ein Blatt (ohne ParentID) übergeben wird, wenn ja, werden alle Datensätze ohne ParentID in sql geschrieben, wenn nein, werden alle Datensätze, die strParent als ParentID haben in sql geschrieben. Dannach wird sql sortiert.
Die Fallunterscheidung beim SQL mußte ich machen, weil wenn sie auch mit ParentID NULL bzw "" funktionieren soll, muß man "IS NULL" statt "= NULL" oder "='' "
schreiben. Das ist eine Besonderheit.
Zitat
Frage: Dabei handelt es sich aber nicht um das rs aus HirachieAuflisten, da du es jeweils nur lokal definiert hast, oder?
Richtig. Das macht die Rekursion aus. Die KinderFunktion ruft für jedes Kind der erhaltenen Parent, die Kinder auf, und für diese Kinder wieder die Funktion Kinder etc. Es gibt also mehrere Aufruf der Funktion Kinder im Stack, und damit auch mehrere Recordsets, die alle lokal definiert sind.
Zitat
Frage: Wenn es Kindeskinder gibt, wird der Text weiter eingerückt und dort dort die Kindeskinder eingetragen, usw. Wenn es keine Kindeskinder gibt, dann wird das Weiterschreiben nicht ausgeführt, da in einer leeren Tabelle rs.EOF sofort erreicht ist, oder?
Richtig. Wenn es keine Kinder mehr gibt, dann wird EOF sofort erreicht, und die Rekursion kommt zum Ende und der Stack baut sich wieder ab.
Zitat
9. Wenn beide Schleifen durchlaufen sind (rs.EOF jeweils erreicht), dann werden die recordsets jeweils geschlossen und gelöscht.
Das Schließen und Löschen ist nicht zwingend nötig, weil lokal verwendete Recordsets aus dem Speicher verschwinden, wenn sie nur lokal definiert sind. Das schreibe ich immer aus Gewohnheit, wenn ich den Rumpf so einer Schleife hinschreibe.
Zitat
Wenn man jetzt aus meiner Importtabelle tblImport , in der die Importdatei eingelesen ist (bei Dir Hierachie), mit Deinen Funktionen eine neue tblImportSort machen will, dann müßte man anstatt einer Textdatei eine neue Tabelle erzeugen?
Ja. Die Ausgabe als Textdatei habe ich nur gemacht, daß es schnell geht. Mir ging es vor allem darum, einen Entwurf für die rekursive Funktion aufzusetzen.
Wenn Du eine sortierte Liste haben willst, mußt Du dafür sorgen, daß Du eine Hilfsvariable für den Sortierindex hat und diesen bei jedem Knoten inkrementieren. Mit dieser kannst Du in die neue sortierte Tabelle mit "INSERT ..." einfügen
Zitat von: Wurliwurm am Juni 18, 2015, 09:55:46
Wenn Du eine sortierte Liste haben willst, mußt Du dafür sorgen, daß Du eine Hilfsvariable für den Sortierindex hat und diesen bei jedem Knoten inkrementieren. Mit dieser kannst Du in die neue sortierte Tabelle mit "INSERT ..." einfügen
Das habe ich nicht verstanden :(
Ich würde jetzt an jeder Stelle, wo Du die strListe weitergeschrieben hast, einen SQL Befehl setzten, der den aktuellen Datensatz in die Tabelle tblImportSort schreibt.
Ungefähr so:
Option Compare Database
Option Explicit
Public Sub HierarchieAuflisten()
[s] Dim strListe As String [/s] 'das wird nicht mehr benötigt'
Dim sql As String
Dim rs As DAO.Recordset
sql = "SELECT * FROM tblImport WHERE ParentAllright_Bauteil_ID IS NULL"
sql = sql & " ORDER BY Allright_Bauteil_ID"
Set rs = CurrentDb.OpenRecordset(sql)
Do Until rs.EOF
[color=red]INSERT INTO tblImportSort (*)
VALUES (rs!*)[/color] 'hier soll der aktuelle Datensatz aus rs in die Tabelle tblImportSort
eigefügt werden'
Call AuflistenKinder(rs!Allright_Bauteil_ID [s], 1, strListe[/s] ) 'es wird nur noch die BauteilID
übergeben'
[s]strListe = strListe & vbCrLf[/s] 'das wird nicht mehr benötigt'
rs.MoveNext
Loop
rs.Close
Set rs = Nothing
[s]Dim strPfad As String
strPfad = getPfad
MsgBox strListe & " ", vbInformation, strPfad & " "
Call LogSchreiben(strListe, getPfad)[/s] 'das wird nicht mehr benötigt'
End Sub
Private Sub AuflistenKinder(ByVal strParent As String[s], ByVal intTiefe As Integer, ByRef strListe As String[/s]) 'das wird nicht mehr benötigt'
Dim sql As String
Dim rs As DAO.Recordset
[s]Dim i As Integer
Dim strPraefix As String
For i = 1 To intTiefe
strPraefix = strPraefix & " "
Next i[/s] 'das wird nicht mehr benötigt'
If strParent = vbNullString Then
sql = "SELECT * FROM tblImport WHERE ParentAllright_Bauteil_ID IS NULL"
Else
sql = "SELECT * FROM tblImport WHERE ParentAllright_Bauteil_ID = '" & strParent & "'"
End If
sql = sql & " ORDER BY Allright_Bauteil_ID"
Set rs = CurrentDb.OpenRecordset(sql)
Do Until rs.EOF
[color=red]INSERT INTO tblImportSort (*)
VALUES (rs!*)[/color] 'hier soll der aktuelle Datensatz aus rs in die Tabelle
tblImportSort eigefügt werden'
Call AuflistenKinder(rs!Allright_Bauteil_ID[s], intTiefe + 1, strListe[/s]) 'das wird nicht
mehr benötigt'
rs.MoveNext
Loop
rs.Close
Set rs = Nothing
End Sub
So wie es da oben steht funktioniert es leider nicht! :(
INSERT INTO tblImportSort (*) 'hier möchte ich alle values beschreiben, daher der *'
VALUES (rs!*) 'hier möchte den kompletten aktuellen Datensatz aus dem recordset in die Tabelle
schreiben'Ich lese mich grade schlau, wie der Befehl richtig ausgeführt soll.
Kann mann überhaupt SQL und VBA so vermischen?
Die tblImport hat jetzt schon über 31 Attribute und es werden immer mehr. Ich wollte ungern alle values nacheinander aufschreiben, daher die Sterne.
Ich geh erstmal schlafen.
Gruß Sparky
[color=red]INSERT INTO tblImportSort (*)
VALUES (rs!*)[/color] 'hier soll der aktuelle Datensatz aus rs in die Tabelle tblImportSort
eigefügt werden'[/quote]
Direkt einen SQL-Befehl hinschreiben geht nicht. Das geht nur in Plattformen welche "direkt die Datenbank eingebaut" sind (T-SQL, PL/SQL, ABAP ...).
Entweder Du konkatenierst einen String und sagst dann
Currentb.Execute(sqlString)
oder Du fügst via Recordset ein:
sqlString = "SELECT * FROM tblNeueTabelle"
Dim rs1 as dao.recordset
set rs1 = currentdb.openrecordset(sqlstring)
rs1.add.new
rs1!Feld1 = "Hallo"
rs1!Feld2 = 4711
rs1.update
rs1.close
set rs1 = nothing
Was ich Dir bei 30 Attributen nahelegen würde, damit es nicht zu lange wird und flexibel bleibt: Bau die neue Tabelle mit den gleichen Attributen auf und füge zusätzlich ein Attribut mit den Sortierindex (Typ Integer) ein
Der Code ginge dann so
Dim i as integer
rs1.addnew
rs1!intSortindex
for i = 0 to rs.fields.count - 1
rs1.fields(rs.fields(i).Name) = rs.fields(i).value
next i
rs1.update
intSortindex ist die Hilfsvariable, die beim Durchlaufen der Knoten inkrementiert wird. Es wird dann aus dem Recordset der alten unsortierten Tabelle der Reihe nach alle Spalten durchlaufen und die Werte übergeben.
Wenn also
rs.fields(1).Name gleich "Feld1" ist, und der Wert rs.fields(1).value gleich "Hallo" dann ist
rs1.fields(rs.fields(1).Name) = rs.fields(1).value
dasselbe wie
rs1!Feld1 = "Hallo"
Leider kann das zur Kompilierzeit nicht geprüft werden, ob alle Attribute gleich sind.