Kombinationsfelder MIT MEHRAUSWAHL voneinander abhängig

[Andi123x4]

Ja genau so ist das gemeint

z.B

Projekt: Haus bauen
Tasks: 1. Fundament Betonieren  2. Grundgerüst bauen 3. Elektronik installieren 4. Fertig stellen
Subtasks: Zu 1. Beton anrühren, Beton eingießen, Beton aushärten lassen
          Zu 2. Grundgerüst skizzieren, Grundgerüst aufstellen, Gerüst befestigen,....

Zu Subtask 1. benötigt man: Rolle -> Bauarbeiter -> Checken z.B Max Meier ist Bauarbeiter.
                            Equipment -> Zement, Eimer, Betonmischer

Hoffe das ist so ersichtlich was das ganze werden soll irgendwann

[DF6GL]

Hallo,

anbei ein Vorschlag..


("Branch" ist mir beziehungsmäßig und bedeutungsmäßig nicht klar)

Evtl. muss aber das Ganze insofern umgestaltet werden, als dass aus einer vorgegebenen Struktur (Vorlage) nur die benötigten Daten einem ProjektSubTask zugeordnet werden. Dafür sind weitere n-Tabellen nötig, die an ProjektSubTask angebunden werden müssen.

[Andi123x4]

Hallo,
Da sie alle Abfragen gelöscht haben sind alle Datensatzquellen weg, deshalb muss ich diese neu hinzufügen
Könnten Sie mir bitte kurz erläutern woher ich weiß welche Tabellen man grundsätzlich braucht als Datensatzquelle ?

Mein Vorgehen:
Ich dachte mir beim Hauptformular brauche ich alle Felder zum Project, darum Reicht die Tabelle Project als Datensatzquelle
Beim Unterformular Tasks brauche ich die Tabelle Tasks für die Felder.

Wenn man alle Felder hat braucht man noch ein Feld über das beide in Beziehung miteinander stehen oder ?
Deswegen habe ich einfach bei der Datzensatzquelle bei Tasks alle Tabellen hinzugefügt, bis man von "PST_ProjectID_F" nach "ProjID" verknüpfen kann.

Das funktioniert aber nicht.

Tut mir leid für diese ganzen banalen Fragen aber ich muss mir alles selbst beibringen und habe keinerlei Hilfe als das Internet und diese Foren.

Danke für die Mühen soweit !

[Beaker s.a.]

Hallo,
Wenn man das Beziehungsfenster (s.Anlage) mal ein bisschen aufräumt, sieht man,
dass es da zwei Beziehungen gibt
"tblPersonalRoles" zu "tblSubtasks" und "tblProjectSubTasks" zu "tblSubTaskEquip",
die ich beide für falsch halte.

gruss ekkehard

[MzKlMu]

Hallo,
das Thema ist ein typisches Beispiel für Beispieldatenbanke die dann an der Realität vorbei gehen.
Ich hatte ja mit den vorleigenden Infos versuch einen Vorschlag für ein Datenmodell zu machen.
Nach den neueren vorleigenden Infos war das für die Katz, denn die Erläuterungen in #30 ist das Datenmodell untauglich.
Ich hatte auch mehrfach mal mach dem Sinn von Subtask gefragt wenn es keine Task gibt. Wurde aber nicht weiter darauf eingegangen.
Die Beziehungen müssen jedenfalls überarbeitet werden, das passt so nicht. Z.B. brauchen die Subtask einen Bezug zum Projekt (Task).

Ich blicke da aber zwischenzeitlich nicht mehr so recht durch.

[Andi123x4]

@DF6GL "Branch" soll anzeigen um welches Tochterunternehmen es sich handelt. Am Ende soll der User vom PC ausgelesen werden und es sollen nur die Projekte/Equipments/Personen der jeweiligen Tochtergesellschaft (Branch) angezeigt werden.

PS. ich habe es mal mit dem Vorschlag probiert, aber da funktioniert gar nichts bei mir, außerdem müsste doch ein Task in den Beziehungen vor dem Subtask kommen und nicht umgekehrt oder nicht ? Quasi als oberste Stufe das Projekt dann Tasks und dann Subtask. In dem Vorschlag kommt ja erst Projekt dann subtask und dann task

@Beaker s.a.
Wieso halten Sie die Beziehung von "tblPersonalRoles" zu "tblSubtasks" falsch ? Ich dachte auch dass man so eine Beziehung braucht um Personal und Rollen den Subtasks zuweisen zu können.
Also ich versuche es nur zu verstehen. Könnten Sie das vielleicht erläutern.

@MzKlMu Es tut mir wirklich leid, hatte vergessen darauf einzugehen. Aber wie sie schon sagten es macht nur Sinn Subtasks zu haben wenn man auch Tasks hat und dies ist ja der Fall, daher die Namensgebung. Ich hoffe mit dem Beispielszenario von oben ist klar was ich hier versuche umzusetzen

[DF6GL]

Hallo,

um welches Tochterunternehmen es sich handelt.

Dann ist das eine Eigenschaft von tblAddresses?

Gehören mehrere User zu einer Branche?


Sind die Tasks auf die Roles oder die Personen bezogen?


Anbei andere Version mit möglicherweise transparenteren Beziehungen. Dabei gibt es aber keine Abhängigkeiten zwischen Tasks, Subtasks, Material, Equipment und Personal (Roles)  .


Alle Forms und Abfragen (bis auf frmHome) sind entfernt, weil hier sowieso nicht mehr brauchbar.

[Andi123x4]

@DF6GL
Danke für den Lösungsvorschlag ich habe es jetzt mal probiert die Formulare nachzubilden auf Ihrer Datenbank, aber hatte dann am Ende wieder das gleiche Problem, dass ich den Tasks keine Subtasks zuordnen kann.
Sie meinten ja sowieso dass es keine Abhängigkeiten zwischen Tasks und Subtasks gibt, sind aber nicht genau diese notwendig für mein Vorhaben, oder wo ist mein Denkfehler ?

VG,
Andi

[DF6GL]

Hallo,

hatte dann am Ende wieder das gleiche Problem, dass ich den Tasks keine Subtasks zuordnen kann.

Das ist doch auch nicht nötig..  Ein Projekt (Haus bauen) besteht aus verschiedene (Haupt-)Tasks, die sich in tblProjectTasks (Fundament ausheben, Bodenplatte giessen) wiederfinden.  Diese Tasks werden aus einer Liste aller möglichen Tasks (tblTasks) ausgewählt und als Schlüsselwert in tblProjectTasks dem Project zugeordnet.


Hat ein Projekttask (Fundament gründen) ) zusätzlich SubTasks (Erdreich ausbaggern, Bodenplatte giessen), so werden diese Subtasks aus tblSubtasks ausgewählt und als Schlüsselwert in tblProjectSubtasks abgespeichert. Zu jedem ProjektSubtask gehören dann weiterhin (mehrere) Materialien (tblProSubTaskMaterial) , mehrere Equipments (tblProSubTaskEquip) und mehrere Rollen (tblProSubTaskRoles) sofern diese bei Euch so zutreffend sind.



(Sehe gerade, dass in den Beziehungen die Tabelle tblRoles noch fehlt)

Hatte vorher schon angedeutet, dass in Version2 keine Abhängigkeit zwischen Tasks und Subtasks existiert.


Wenn das gewünscht ist, muss zusätzlich in tblSubtask ein Fremschlüsselfeld (SubT_TaskID_f) für tblTasks.TaskID   eingesetzt und mit tblTasks.TaskID in n:1-Beziehungen definiert werden.

[Andi123x4]

Also es ist zwar nicht nötig um Tasks und Subtasks speichern zu können, aber dann sind Task und Subtasks ja unabhängig von einander in der aktuellen Version und das ist ja wie schon erwähnt nicht gewollt.
Es soll nur "Subtasks" geben können, wenn es dazu auch einen (Über)"Task" gibt, und diese "Tasks" müssen immer zu einem bestimmten Projekt gehören.

Ich habe jetzt mal alle Formulare in Ihrer Datenbank nachgebildet, aber schaffe es irgendwie nicht die Tasks und Projects zu verknüpfen. Bei Subtasks und Projects funktioniert es.

Auch habe ich die besagte Beziehung zwischen Tasks und Subtasks hergestellt, wie Sie meinten, aber ich kann trotzdem den Tasks im Formular nicht direkt Subtasks zuweisen. Könnten Sie das bitte ergänzen oder am besten erklären was fehlt, damit man im Formular   "frmProjects", auf die Tasks drückt und dann die Subtasks zuweisen kann?

[DF6GL]

Hallo,

ich verstehe deine "Task"-Vorstellung nicht.


Meine Vorstellung der Situation:

Es gibt ein Projekt (tblProjekt).

Ein Projekt kann mehrere Tasks umfassen (tblProjectTasks). Diese Tasks werden aus einem Kontingent aller möglichen Tasks einzeln (PT_TaskID_f) ausgewählt. Dieses Kontingent aller möglichen Tasks muss vorher definiert (erfasst) werden  --> tblTasks füllen.

Jeder Task kann mehrere SubTasks enthalten (tblSubTasks definieren).

Jeder ProjectTask kann mehrere SubTasks (aus Tabelle tblSubtasks, die in Abhängigkeit zu tblTasks steht) enthalten (tblProjectSubTasks).

Jeder von diesen "ProjectSubTasks"  kann wiederum mehrere Materialien, Equipments und Rollen besitzen, die in den entspr. Tabellen hinterlegt werden.


damit man im Formular   "frmProjects", auf die Tasks drückt und dann die Subtasks zuweisen kann?

Dafür ist das Formular falsch aufgebaut.

Das HFO muss sich auf tblProjects beziehen.
Darin steht ein UFO mit Bezug auf tblProjectTasks und Verknüpfung über die Schlüsselfelder (PID---PT_PID_f).

In diesem UFO wiederum ein UFO im Fußbereich mit Datenherkunft tblProjectSubtasks mit Verknüpfung über deren Schlüsselfelder.


Wenn allerdings ein "Projekt" identisch ist mit einem "Task"   ("Haus bauen"), dann kann auf die Tabelle "tblProjectTasks" ganz verzichtet werden.

[Andi123x4]

Doch das ist schon genauso wie Sie meinen, aber so meine ich es doch auch

1 Projekt besteht aus 1-n Tasks und jeder Tasks besteht aus 1-n Subtasks

Das einzige wäre noch, dass die Tasks und Subtasks eigentlich nicht vorher definiert werden sollen, sondern lediglich gespeichert, damit man gegebenenfalls Tasks und subtasks aus vorherigen projekten wiederverwenden kann. Man soll aber auch Tasks und Subtasks beim Projekt erstellen neu eingeben können.

Im Prinzip will ich einfach ein neues Projekt anlegen, und wenn ich auf einen Task drücke dazu die Subtasks zuweisen, aus dem einfachen grund, dass man dann einfach navigieren kann man drückt z.B auf "Task 3" und enthält dazu alle Subtasks, Equipments, Rollen und Personen.

Die Idee mit den 2 Unterformularen würde aber bedeuten, dass das "Task" Ufo ein Einzelformular sein muss und dann habe ich in der Übersicht nicht alle Tasks sondern nur eines oder geht das auch anders ?

Bild als Beispiel wie ich es mir gewünscht hätte

[DF6GL]

Hallo,

Man soll aber auch Tasks und Subtasks beim Projekt erstellen neu eingeben können.

Das löst man mit Hilfe des "Bei nicht in Liste" (siehe VBA-Hilfe) der einzelnen Kombifelder, so dass die Tasks/Subtasks praktisch vor deren Auswahl definiert worden sind.

Durch die ref. Int. Beziehungen ist dies zwingend erforderlich.

nicht vorher definiert werden sollen, sondern lediglich gespeichert, damit man gegebenenfalls Tasks und subtasks aus vorherigen projekten wiederverwenden kann

Es müssen die Tasks und Subtask vor der weiteren Auswahl in ProjectTasks und ProjectSubtasks definiert sein, entweder anfänglich durch "Eingabe/Pflege" oder dann, wenn es erforderlich ist, mittels o. g. Ereignisprozedur.

Dadurch ist die Forderung nach Wiederverwendbarkeit grundsätzlich erfüllt.

dass das "(Project-)Task" Ufo ein Einzelformular sein muss

 steht nirgends in Stein gemeiselt. Das kann sehr wohl ein Endlosform sein.


Lediglich beim Form "frmProjectSubTasks", das in den Formularfuß von (UFO) "frmProjectTasks" platziert werden soll. wird Access maulen, dass das nicht gehen soll. Man stellt einfach danach das UFO wieder auf Endlosform um, und Access ist wohlgesinnt.

[MzKlMu]

Hallo,

man drückt z.B auf "Task 3" und enthält dazu alle Subtasks, Equipments, Rollen und Personen.

Diese Anforderung stellt alles was bisher gemacht wurde auf den Kopf.
Wenn Du das so willst, so müssen die ganzen Zusammenhänge erst mal in Tabellen definiert werden.
Das ist völlig unabhängig vor der späteren Zuordnung der Tasks/Subtasks zu dem Projekt.
Die definierten Zuordnungen bleiben immer bestehen und aus diesen werden dann die zu einem Projekt vorhanden Aufgaben/Uneraufgaben zugeordnet.
Das gibt der bisherige Tabellenaufbau nicht her.

Ich glaube, Du unterschätzt hier den Aufwand ziemlich.

PS:
Hier im Forum ist es Usus, dass man sich Duzt. Solltest Du eigentlich schon gemerkt haben.

[DF6GL]

Hallo,

@klaus:

Das gibt der bisherige Tabellenaufbau nicht her.

siehe : https://www.access-o-mania.de/forum/index.php?topic=26068.msg155562#msg155562