Hallo zusammen...
Im Forum habe ich nichts entsprechendes gefunden, deshalb frage ich einfach mal.
Stellt euch vor, es gibt ein Projekt dass aus einer gewissen Anzahl von "Scheiben" besteht.
Jede Scheibe besteht aus einer gewissen Anzahl von "Rohren".
Jedes Rohr hat eine gewisse Anzahl von "Schweißnähten".
Also beispielsweise 30 Scheiben a 5 Rohre mit jeweils 4 Schweißnähten.
Ich habe also eine Tabelle [Scheibe], [Rohr], [Naht], mit weiteren Feldern in die später über ein Formular Eintragungen gemacht werden.
Nun habe ich für ein bestimmtes Projekt mal eine entsprechende Excel-Tabelle erstellt und dann die Werte in die Access_Tabelle ("tbl_Arbeitsblatt") per Drag and Drop eingefügt. Funktioniert, ist aber nicht besonders elegant.
Gib es eine Möglichkeit, für andere Projekte (die Anzahl der Scheiben, Rohre und Schweißnähte variieren dabei) die tabelle über ein Formular zu füllen indem ich Beispielsweise "Anzahl der Scheiben", "Anzahl der Rohre" und die "Anzahl der Schweißnähte" eingebe und Access füllt die Tabelle automatisch?
Ich hoffe, ich habe mich verständlich ausgedrückt...
Hallo,
nach 30 Beiträgen hast Du noch nichts von Beziehungen, Primär-/Fremdschlüsseln, gebundenen Formularen, bzw. Unterformularen gehört?
ZitatIm Forum habe ich nichts entsprechendes gefunden
Nach was und wie hast Du denn gesucht?
ZitatGib es eine Möglichkeit, für andere Projekte (die Anzahl der Scheiben, Rohre und Schweißnähte variieren dabei) die tabelle über ein Formular zu füllen indem ich Beispielsweise "Anzahl der Scheiben", "Anzahl der Rohre" und die "Anzahl der Schweißnähte" eingebe und Access füllt die Tabelle automatisch?
Welche Tabelle meinst Du hier? Falls es sich um das Excel-Sheet handelt: vergiss es.
Warum macht Du die Eingaben nicht direkt in Access über die Formulare, die Du lt.
ZitatIch habe also eine Tabelle [Scheibe], [Rohr], [Naht], mit weiteren Feldern in die später über ein Formular Eintragungen gemacht werden.
ja schon hast ?
Ich verstehe Dein Problem nicht.
Hallo Franz,
Stimmt, ich habe eine entsprechende Tabelle die ich für dieses eine Projekt auf beschriebene Weise (ich schäme mich ja auch dafür) für die weitere Bearbeitung ausgefüllt habe.
Das Ziel ist, anderen die das Projekt später abwickeln werden, eine Arbeitsunterlage zu schaffen in der alle geplanten Arbeiten bereits enthalten sind und die dann nur noch dokumentarisch z. bsp. die Schweißer und die gemachten Prüfungen an den jeweiligen Nähten eintragen brauchen.
Also im Beschriebenen Fall sind es 30 x 5 x 4 Nähte, also 600 Datensätze.
Es können aber auch deutlich mehr sein.
Also möchte ich gerne ein Formular, in dem ich Access sagen kann, fülle bitte die (für ein neues Projekt natürlich leere) Tabelle in der beschriebenen Form.
Also [Scheibe] 20 mal die "1" untereinander, dann 20 x die "2" untereinander und so weiter.
Im Feld [Rohr] 4 x die "1" untereinander, dann 4 x die "2" untereinander und so weiter und im Feld [Naht] immer wieder die Zahlenfolge "1", "2", "3" und "4" untereinander.
So dass ich beispielsweise im 10. Datensatz die Werte [Scheibe]="1"; [Rohr]="3" und [Naht]="2" stehen habe.
Hallo,
es sind nötig:
tblProjekte:
PRID (PK, Auotwert)
PR_Bezeichnung (Text)
.
.
tblScheiben:
SchID (PK, Autowert)
Sch_PRIF (FK)
Sch_Bezeichnung (Text)
.
.
tblRohre:
RoID (PK)
Ro_SchID (FK)
Ro_Bezeichnung (Text)
.
.
.
tblNähte:
NaID (PK)
Na_RoID (FK)
Na_Bezeichnung (Text)
Na_Bewertung (Text bzw. Memo) ' evtl. Na_BWID (FK) , wenn mögliche Bewertungen in weiterer 1-Tabelle "tblBewertungen" erfaßt werden können.
Beziehungen 1:n über die Schlüsselfelder.
Zu jeder Tabelle ein Endlosform. Evtl. ein Einzelform für tblProjekte.
In frmProjekte kommt ein UFO-Steuerelement zu stehen, das frmScheiben als UFO anzeigt.
In frmScheiben kommt ein UFO-Steuerelement im Formularfuß zu stehen, das frmRohre anzeigt.
In frmRohre kommt ein UFO-Steuerelement im Formularfuß zu stehen, das frmNähte anzeigt.
Um ein neues Projekt insgesamt mit allen seinen Scheiben/Rohren und Nähten zu "erfassen" , erstelle im frmProjekte im Form-Kopf oder -Fuß drei ungebundene Textfelder (txtAnzScheiben, txtAnzRohre, txtAnzNähte) und eine Schaltfläche (btnProjektNeu), die mittels der Anzahl-Angaben und den Primärschlüssel-, bzw. Fremdschlüsselwerten) die entsprechenden DS in den Tabellen generiert (SQL (empfohlen) oder mittels Recordsets.)
Ich danke dir...
das klingt jetzt etwas komplizierter als ich gehofft habe.
mal sehen, ob ich das umsetzen kann.
Um das ganze Benutzerfreundlich zu gestalten muss alles natürlich irgendwie in einer Ansicht landen in der er schnellstmöglich zu der jeweiligen Schweißstelle springen kann.
Momentan habe ich alle Schweißnähte hübsch untereinander in der beschriebenen Form und man kann auch nach den Kriterien filtern...
Es soll halt übersichtlich und einfach sein.
danke für deine Mühe
LG Bernd
Hallo,
wenn Du die Tabellenkonstuktion korrekt aufbaust, wird alles ganz einfach.....
Zitatin der er schnellstmöglich zu der jeweiligen Schweißstelle springen kann.
Wenn die "Nummer", bzw. Bezeichnung einer Schweißnaht an einem bestimmten Rohr an einer bestimmten Scheibe und bzgl. einer Projektnummer bekannt ist, ist das "Springen" (Filtern) dorthin eines der leichtesten Übungen....
Hallo Bernd,
Zitatwenn Du die Tabellenkonstuktion korrekt aufbaust, wird alles ganz einfach.....
Das ist erstmal das Wichtigste. Zeige also zunächst mal das Bild des
Beziehungsfensters. Weiss gar nicht warum Franz nicht schon da nach
gefragt hat.
Für "kompliziert" halte ich nur den Entwurf des Formulars wegen der
von Franz angedeuteten mehrstufigen UFo-Hierarchie.
gruss ekkehard
Hallo
ZitatWeiss gar nicht warum Franz nicht schon da nach
gefragt hat.
Weil das Beziehungsfenster wegen
ZitatIch habe also eine Tabelle [Scheibe], [Rohr], [Naht], mit weiteren Feldern.. i
gleich erschlagen hätte. ;D ;)
Hallo nochmal.
Ich erstelle gerade zu testzwecken eine neue Datenbank nach dem Muster von Franz.
Die Tabellen sind erstellt.
In das "frm_Projekte" (einzelnes Formular) habe ich, wie beschrieben, das Formular "frm_Scheiben" hineingezogen und es wird mir als Unterformular angezeigt. - soweit gut
In das "frm_Scheiben" (Endlosformular) versuche ich nun das Formular "frm_Rohre" in den Formularfuß zu ziehen und bekomme eine Fehlermeldung. "Die Standardansicht-Eigenschaft eines Formulars, das ein Unterformular hat, kann nicht auf Endlosformular festgelegt werden"
Bei Druck auf OK fügt Access "frm_Rohre" zwar in den Formularfuß ein, aber das frm_Scheiben wird auf Einzelformular zurückgesetzt.
Ich habe es danach wieder auf "endlos" gesetzt. Alles gut.
Das Gleiche mit "frm_Rohre".
Ich habe die Textfelder für die Anzahl der Scheiben, Rohre und Nähte eingefügt und auch den Button.
Nun kenne ich den Code nicht, den ich dort hinterlegen soll.
Wie geht das mit den Recordset?
Hallo Bernd,
Vergiss doch erstmal das/die Formular(e). Zeige das Beziehungsfenster
so wie du es jetzt hast. Eine DB mit ein paar Spieldaten wäre auch
nicht schlecht.
Ich befürchte nämlich, dass dieses von Franz skizzierte DM nicht aus-
reichen wird. Bis jetzt ist auch immer nur von einer unterschiedlichen
Anzahl von Bauteilen die Rede.
Aber was ist mit denen an sich?
Da gibt es doch sicherlich verschiedene Scheiben/Rohre/Nähte. Daher denke
ich, dass da wohl noch die eine oder andere n:m-Tabelle nötig ist.
gruss ekkehard
Hallo Ekkehard,
Ich habe mal meine Datei in den Anhang gelegt.
Ziel soll sein, das Access neue Datensätze wie in der tbl_Arbeitsblatt automatisch anlegt.
Z.B. bei einem neuen Projekt.
Hallo,
ZitatZiel soll sein, das Access neue Datensätze wie in der tbl_Arbeitsblatt automatisch anlegt.
Ziel ist
zuerst, die Tabellenstruktur korrekt aufzubauen und Beziehungen zu setzen und ein paar Grundregeln bei der Benamsung zu beachten:
Sonder- und Leerzeichen vermeiden (hier: "-")
Eindeutige Feldnamen
DB-weit benutzen ("ID" z. B.: PrID in tbl_Prüfer)
Tabellen entspr. der Bedeutung ihrer Daten benennen (tbl_Grunddaten: ?? )
tbl_WPS ist unbrauchbar, weil nicht normalisiert. Was soll diese Tabelle überhaupt darstellen? Schweißmaterial für die einzelnen Nähte?
tbl_Nummerierung ist in dieser Form vermutlich auch überflüssig.
Zitat... nach dem Muster von Franz.
naja, nicht so ganz.... ::) Ich sehe keine einzige Tabelle aus meinem Vorschlag, und schon gar keine Fremschlüssel und Beziehungen.
Baue also die DB (eine neue) so auf wie vorgeschlagen. Wenn entspr. des Hinweises von Ekkehard weitere Tabellen nötig sind, baue diese nach gleichem Muster ein und setze die Beziehungen(!).
@Ekkehard: Völlig richtig... Meine Vorschläge sind immer die minimalesten bezgl. des Tabellenaufbaus. Anfänglich ist oftmals (in den meisten Fällen) unklar, was uberhaupt datenmäßig Sache ist. ;)
Hallo Franz,
sei doch nicht immer so streng mit mir...
Ich hatte Ekkehard so verstanden, dass er die Ursprungsdatei sehen wollte.
In der tbl_WPS meinst du wahrscheinlich die Einträge "4-7,1".
Die werden lediglich informativ angezeigt. Wichtig ist die Zuordnung der WPS-Nr. zur jeweiligen Schweißaufgabe im frm_Arbeitsblatt_Liste.
(WPS=Welding Prozedure Specification=Schweißanweisung)
In der WPS stehen alle Parameter die für die Ausführung dieser Naht zu beachten sind.
Ich hänge jetzt die Datei "Test1" an die Mail.
Die habe ich so gebaut, wie ich deine Vorgaben verstanden habe.
Der Idealfall wäre, ein Formular zu haben, in dem ich die Anzahl der Scheiben, die Anzahl der Rohre/Scheibe und die Anzahl der Nähte/Rohr eingeben könnte und die Werte landen in einer Tabelle (so wie in tbl_Arbeitsblatt).
Ist das möglich?
LG Bernd
Hallo,
naja, "streng" sieht bei mir schon noch anders aus.. ;) ;D 8)
Als nächste Hausaufgabe: :)
Erzeuge eine Tabelle tbl_WPS für die Erfassung der vorhandenen Schweissanweisungen und setze Beziehungen zwischen den Tabellen wie im Bild.
Korrigiere die Fehler enstpr. der auftretenden Meldungen.
ZitatDer Idealfall wäre, ein Formular zu haben, in dem ich die Anzahl der Scheiben, die Anzahl der Rohre/Scheibe und die Anzahl der Nähte/Rohr eingeben könnte und die Werte landen in einer Tabelle (so wie in tbl_Arbeitsblatt).
Wörtlich genommen geht das nicht, d.h. es wäre ein db-technischer Irrweg. Mit Formularen (und auch Abfragen) befassen wir uns später, wenn die Tabellenkonstruktion die reale Umgebung exakt und vollständig beschreibt.
Hallo Franz,
Habe ich gemacht. Sieht so aus wie im Screenshot.
Ich musste mache Feldtypen in "Zahl" ändern.
Ich nehme an, du meintest das mit
"Korrigiere die Fehler enstpr. der auftretenden Meldungen."
Ich muss zugeben, dass ich Tabellen noch nie auf diesem Weg verknüpft habe.
In der Regel arbeite ich einfach mit Abfragen in die ich die entsprechenden Tabellen einfüge.
Welchen Vorteil hat es das so zu machen? Ich frage wirklich weil ich das nicht weiß...
Ich brauche für die Dokumentation ja noch andere Tabellen.
Wie in der Datei die ihr schon habt.
Z.Bsp. müssen die Schweißer noch erfasst werden über eine Schweißernummer und später der Naht zugeordnet werden können.
Hallo,
Zitat von: undefinedWelchen Vorteil hat es das so zu machen?
Erst wenn Beziehungen angelegt sind, wird das zu einer Datenbank, vorher ist das ein Datenhaufen. Im Beziehungsfenster sind das auch keine Verknüpfungen, sondern Beziehungen, die können gelich sein, müssen aber nicht. Verknüpfungen gibt es ausschließlich in Abfragen und dort kannst Du Verknüpfungen anlegen, die völlig anders sind als die Beziehungen und trotzdem sinnvoll sein.
Beziehungen sind das A+O einer Datenbank. Hier (und nur hier) kann auch referentielle Integrität (RI) eingestellt werden, die sicherstellt dass die Daten in sich stimmig (konsistent) sind. So ist es mit RI nicht möglich eine Naht anzulegen, wenn es kein übergeordnetes Rohr gibt. Kein Rohr ohne Scheibe und keine Scheibe ohne Projekt.
Beziehungen(und das Wissen darüber) sind absolute Grundlagen wenn man eine Datenbank entwickeln will.
Und, Access muss man lernen, da kann man nicht einfach mal so anfangen wie bei Word und Excel. Bei Access geht nichts intuitiv.
Siehe hierzu:
https://www.access-tutorial.de/
Nachtrag:
Auch für die Schweißer ist dann eine Tabelle notwendig, deren Primärschlüssel dann in der Naht (als Fremdschlüssel) erfasst werden.
HAllo,
Zitatich brauche für die Dokumentation ja noch andere Tabellen.
Eben, Du(!) musst zuerst
alle erforderlichen Tabellen erstellen und nach den jetzt bekannten Schema in Beziehung zueinander setzen.. Da kommt Ekkehard's Hinweis wieder zum Tragen.
Sonst wird das nichts mit einer Dokumentation, die ja ein Ergebnis aus den DB-Daten darstellt.