August 11, 2022, 04:39:40

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Kombinationsfelder MIT MEHRAUSWAHL voneinander abhängig

Begonnen von Andi123x4, April 07, 2022, 13:14:57

⏪ vorheriges - nächstes ⏩

DF6GL

April 30, 2022, 08:56:13 #60 Letzte Bearbeitung: April 30, 2022, 09:36:48 von DF6GL
Hallo,


ZitatFormular "frmTaskAcquisition" an, da ist das ganze ja schon umgesetzt so wie du meinst denke ich, dieses würde ich auch gerne hernehmen für die Rollen + Personen und Equipments.

Die (Beziehungs-)Situation ist mit (dem UFO in) diesem Form nicht richtig umgesetzt. Ich hatte schon mal angedeutet, als Datenherkunft keine verknüpfende Abfrage, schon gar nicht über 4 Tabellen hinweg zu verwenden, sondern den entspr. Tabellenamen einzusetzen. Wirf die "xxxxAcquisitionxxx"-Formulare in die Tonne.

ZitatEigentlich müsste ja die Tabelle "tblProSubTaskRoles" die Datensatzquelle sein oder? weil darin will ich ja die Rollen und Personen speichern welche ich aus "tblPersonalRoles" ausgewählt habe, oder geht das mit der aktuellen Struktur nicht was ich vorhabe ?

Wie vorher schon gesagt, musst Du dich entscheiden, ob Rollen oder Personen einem  "ProjectSubTask" direkt zugeordnet werden sollen. Die aktuelle Beziehungsstruktur gibt nur her, dass zu einem "ProjectSubTask" eine oder mehrere Rollen abgelegt werden können ("tblProSubTaskRoles"). Die einzelnen Peronen können trotzdem in Form eines Listenfeldes oder kleinem Unterformular zu Anzeige gebracht werden. Lediglich die "Auflösung" ist rollenbezogen  und nicht personenbezogen.


Schau Dir doch einfach die Beziehungen an!



Ausgewählt und abgelegt wird nur jeweils eine "PersonalRolle" ( vielleicht wäre als Tabellenname "tblRolePersonal" etwas geschickter und verständlicher), die in Tabelle "tblProSubTaskRoles" gespeichert wird.



Als Formular-Konstruktion könnte dies realisiert werden:


(Prämisse:  1- Tabellen (je nach "Point of view") werden als HFO ausgeführt.  Dazugehörende n-Tabellen sind UFOs in diesem HFO.  Weitergehende n-Tabellen werden als weitere UFOs in den vorhergenden UFOs eingesetzt.)


HFO: "frmProjectTasks
darin UFO: "frmProjectSubTasks"
darin UFO: "frmProSubTaskRoles"
darin Auswahl der gewünschten Rolle mittels gebundenem Kombi (Steuerelementinhalt: "PStRoles_PDID_f")  mit Datenherkunft "tblPersonalRoles" .

Das Gleiche passiert mit "Equipments".



Eigentlich sollte es jetzt klar werden.





Andi123x4

Zitat[...]schon gar nicht über 4 Tabellen hinweg zu verwenden, sondern den entspr. Tabellenamen einzusetzen. Wirf die "xxxxAcquisitionxxx"-Formulare in die Tonne.

Ja sorry das war noch von Anfangs, hatte ich vergessen zu ändern, aber ist jetzt ohnehin verworfen

ZitatWie vorher schon gesagt, musst Du dich entscheiden, ob Rollen oder Personen einem  "ProjectSubTask" direkt zugeordnet werden sollen. Die aktuelle Beziehungsstruktur gibt nur her, dass zu einem "ProjectSubTask" eine oder mehrere Rollen abgelegt werden können ("tblProSubTaskRoles").
Ahhh oke ja jetzt verstehe ich das Ganze was du meinst! Jetzt da ich es (wie ich denke) verstanden habe erscheint es offensichtlich aber ich hatte es zuerst nicht verstanden.

Nun aber 2 Fragen dazu:
(1) Wieso soll das HFO "frmProjectTasks" sein, und nicht "frmProjectSubTasks", weil in ersterem werden ja die Tasks gespeichert aber die Rollen, Equipments stehen ja mit "Subtasks" in Beziehung, sollte deshalb nicht besser "frmProjectSubTasks" das HFO sein?

Zitatdarin Auswahl der gewünschten Rolle mittels gebundenem Kombi (Steuerelementinhalt: "PStRoles_PDID_f")  mit Datenherkunft "tblPersonalRoles"
(2) Das ergibt für mich Sinn was du sagst mit der Zuteilung, und ich habe es so umgesetzt, nur wenn ich als Datenherkunft "tblPersonalRoles" hernehme, kann ich ja nur ID's wählen, weil in dieser Tabelle nur die ID's von "tblRoles" und "tblPersonal" gespeichert sind. Wie kann man das umgehen ?

Ich habe es mal so umgesetzt wie in (1) beschrieben, und beim letzten UFO als Datenherkunft "tblPersonal" und "tblRoles" verwendet um die namen zu sehen, aber die Auswahl würde ja trotzdem über die ID erfolgen und nicht über den Namen

Andi123x4

Nachtrag:
Wenn es in diesem Fall ok ist verknüpfte Tabellen zu verwenden, dann würde ich bei der Auswahl als Datenherkunft "tblPersonalRoles" mit "tblPersonal" und "tblRoles" verknüpfen, dann könnte man Rolle und Nachname anzeigen lassen anstatt den Primärschlüssel dieser beiden Felder ?

DF6GL

Hallo,

ich glaube, Du verstehst das grundlegende Prinzip nicht ganz...


Du solltest Dir einmal Gedanken dazu machen, WIE die DB überhaupt bedient werden soll.

D. h. wann, wie und wo Daten vom User aus betrachtet bearbeitet werden sollen/müssen.







Zitatsollte deshalb nicht besser "frmProjectSubTasks" das HFO sein?

Das kommt auf den Bearbeitungs-Vorgang an (zu dem Du wie oben gesagt, erst mal Dir klarheit verschaffen musst.


Wenn ein User so ein Formular zur Bearbeitung (Zuordnung) von Equipments zu ProjectSubTasks vorgesetzt bekommt, muss er zunächst das Projekt, den passenen ProjectTask und den wiederum dazu passenden ProjectSubTask auswählen und filtern.


Das müsste dann über eine dreifach abhängige Kombifeld-Konstruktion geschehen.




Mit

ZitatHFO: "frmProjectTasks
darin UFO: "frmProjectSubTasks"
darin UFO: "frmProSubTaskRoles"
darin Auswahl der gewünschten Rolle mittels gebundenem Kombi (Steuerelementinhalt: "PStRoles_PDID_f")  mit Datenherkunft "tblPersonalRoles" .

Das Gleiche passiert mit "Equipments".

brauchst Du nur im HFO ein Project auswählen und Du hast alle "darunterliegenden" Daten im Zugriff.


Um auch die eigentlichen Project-Daten im Form "frmProjectTasks" anzuzeigen, kann man hier für die Datenherkunft jetzt eine über tblProjects und tblProjectTasks" verknüpfende Abfrage einsetzen.



Zitataber die Auswahl würde ja trotzdem über die ID erfolgen und nicht über den Namen

Die (Verwendung der) Auswahl erfolgt IMMER über die ID-Felder (Schlüsselfelder), das Auslesen der Namen geschieht über eine passende Abfrage eines Auswahlkombis und die eigfentliche Anzeige mittels Textfeld, dem der Inhalt der entspr. Kombifeld-Spalte zugewiesen wird

(Steuerelementinhalt:  = Kombifeldname.Column(1)   )



Lad nochmal den aktuellen Zustand der Db hier hoch.

Andi123x4

Ja ich gebe dir recht, aber die Zuteilung erfolgt aktuell im Form "frmProjectJob" über einen Doppelklick auf eine SubID, so hat der User ja schon einen bestimmten Datensatz ausgewählt.

Im Anhang mal die aktuelle Version,
Ich weiß nur noch nicht wie ich die richtigen Equipments/Rollen/Personen anzeigen lassen, die Zuteilung glaube ich ist korrekt.
Ich hatte versucht in den "Kriterien" des Listenfeldes Equipment die Datensatzherkunft zu filtern, über die "PSTID" aber das funktioniert nicht.

Und wenn ich beim Listenfeld von Rollen+Personen die Namen angezeigt haben will müsste ich wieder 4 Tabellen miteinander verknüpfen, was man nicht machen soll

PS. Das mit dem in eine neue Datenbank kopieren war ein guter Tipp, so komme ich von 5MB auf 2MB und dann mit ZIP auf 180KB

DF6GL

Mai 03, 2022, 12:40:53 #65 Letzte Bearbeitung: Mai 03, 2022, 12:52:47 von DF6GL
Hallo,

wo sind die Beziehungen geblieben ???  ?? 


Erzeuge die (wieder) im Beziehungsfenster ..

In welchem Zusammenhang tblUser, tblBranches und tblAdresses stehen sollen, erschliesst sich mir (immer) noch nicht.

Was soll tblChecklist bewerkstelligen?

DF6GL

Mai 03, 2022, 13:12:51 #66 Letzte Bearbeitung: Mai 03, 2022, 13:31:35 von DF6GL
Hallo,

ZitatUnd wenn ich beim Listenfeld von Rollen+Personen die Namen angezeigt haben will müsste ich wieder 4 Tabellen miteinander verknüpfen, was man nicht machen soll

Niemand sagt das.  Wenn man Daten aus 4 Tabellen braucht, dann benutzt man eine über diese Tabellen verknüpfende Abfrage.  Unzweckmäßig ist das bei der Datenherkunft von Formulare, weil eine solche Abfrage redundante Daten liefert und in den vielen Fällen nicht aktualisierbar ist (--> keine Änderung an den Daten ermöglicht).

Bau einfach mal ein Form wie vorher gesagt auf, und ohne Schnickschnack einzubauen.





Dabei kann tatsächlich eine über tblProjects und tblProjectTasks verknüpfende Abfrage für die Datenherkunft von "frmProjectTasks" benutzt werden, um die einzelnen Project-Daten anzeigen zu können.


Wirf bei allen anderen Forms die (eh falschen) Abfragen aus der Datenherkunft heraus und setze die zugrundeliegenden Tabellennamen ein.

Wenn Du Listenfelder für die Anzeige der Daten aus n-Tabellen verwenden willst, müssen diese Abfragen mit dem entspr. Schlüsselfeld synchronisiert (d. h. gefiltert werden, sonst bekommst Du alle Daten aus der n-Tabelle ohne Bezug zum akt. ProjectSubTask zu Gesicht. Allerdings funktioniert ein Listenfeld nicht ohne weiteres in einem Endlos-Formular im Detailbereich.  Ein Unterform ist zweckmäßiger und auch nur im Formularfuß.





Andi123x4

Ohhh, Dann hat das mit dem Daten in eine neue DB kopieren doch nicht so gut funktioniert, ich habe einfach alle Formulare Tabellen markiert und mit STRG+C STRG+V in eine leere Datenbank kopiert, hatte gehofft die Beziehungen werden auch übernommen.

Also Das Tool wird für mehrere (Zweigstellen/Tochtergesellschaften/Branches) verwendet.

Zu beginn soll per VBA der USER ausgelesen werden, und von welchem "Branch" der User ist.
Dann sollen diesem User nur die Projekte des jeweiligen "Branch" angezeigt werden.
Also sollen die Firmen aus Spanien nur spanische Projekte sehen und wenn ein Deutscher "User" erkannt wird nur deutsche Projekte.

Und die verschiedenen (Zweigstellen/Tochtergesellschaften/Branches) haben Adressen.

Also
Address - Branch -> 1:1
Branch - User    -> 1:N

Für die tblChecklist soll noch ein Formular erstellt werden, über das man eine Checkliste für ein Projekt erstellen kann.

Ich dachte dass ich dann eben nach der PSTID filtern muss und zwar indem ich beim Listenfeld das einfüge:
[Formulare]![subfrmTask]![frmSubtask].[Formular]![PSTID]

Ich habe mal im frmnProjectJob die PSTID hinzugefügt, zu Veranschaulichung ob ich auf dem richtigen Weg bin ?

DF6GL

Mai 03, 2022, 13:54:59 #68 Letzte Bearbeitung: Mai 03, 2022, 14:25:01 von DF6GL
Hallo,

Zitat von: undefinedich habe einfach alle Formulare Tabellen markiert und mit STRG+C STRG+V in eine leere Datenbank kopiert,

Das ist zu "einfach"


Man verwendet die Import-Funktion von Access, um aus einer anderen DB alle Objekte in eine neue DB zu "importieren", nicht C&P.


Zitat von: undefinedIch dachte dass ich dann eben nach der PSTID filtern muss und zwar indem ich beim Listenfeld das einfüge:
[Formulare]![subfrmTask]![frmSubtask].[Formular]![PSTID]



[Quote}Für die tblChecklist soll noch ein Formular erstellt werden, über das man eine Checkliste für ein Projekt erstellen kann.[/Quote]


Vergiss doch mal die Formulare...............

Ich versteh die "Checkliste" jetzt nur als Schmierzettel, vornehmer ausgedrückt als Notizblock mit irgendwelchen Bemerkungen zu einem Projekt.

Soll heißen: Einträge in tblChecklist werden einem Project zugeordnet.


Theoretisch schon, aber es funktioniert nicht bei einem Endlosform wie man es erwartet.

Zitat von: undefinedIch habe mal im frmnProjectJob die PSTID hinzugefügt, zu Veranschaulichung ob ich auf dem richtigen Weg bin ?



Wie gesagt, wäre schon richtig, wenn es denn funktionieren würde.

Einzig ein UFO(-Steuerelement)  (wie schon mehrmals gesagt) kann über seine Eigenschaften "Verknüpfen von/nach" und seine Platzierung im Formularfuß die Aufgabe erfüllen.



Bezgl. "Branch":

Ein "Branch" ist eine Zweigstelle mit all ihren Daten, einschließlich Adresse, der beliebig viele Projekte zugeordnet werden können/sollen.

Einer "Branch" können beliebig viele User zugeordnet werden.

So sind die Beziehungen im Bild eingestellt.

Andi123x4

ZitatMan verwendet die Import-Funktion von Access, um aus einer anderen DB alle Objekte in eine neue DB zu "importieren", nicht C&P.
Alles klar dann weiß ich das jetzt fürs nächste mal :)
ZitatIch versteh die "Checkliste" jetzt nur als Schmierzettel, vornehmer ausgedrückt als Notizblock mit irgendwelchen Bemerkungen zu einem Projekt.
Ja stimmt verstehe ich, macht Sinn

ZitatEinzig ein UFO(-Steuerelement)  (wie schon mehrmals gesagt) kann über seine Eigenschaften "Verknüpfen von/nach" und seine Platzierung im Formularfuß die Aufgabe erfüllen.
Du meinst so in etwa wie das mit Tasks und Subtasks umgesetzt wurde im Formularfuß?
Ich kann dir leider nicht genau folgen wie du das meinst. Meinst du für die Anzeige der beiden Listenfelder Roles/Personal und Equipments ein weiteres UFO anlegen und dann in die Fußzeile von "subfrmSubtask" und dann verknüpfen mit der "PSTID"?





DF6GL

Hallo,

ZitatMeinst du für die Anzeige ...ein weiteres UFO anlegen und dann in die Fußzeile von "subfrmSubtask" und dann verknüpfen mit der "PSTID"?



Ja

Andi123x4

ZitatMeinst du für die Anzeige ...ein weiteres UFO anlegen und dann in die Fußzeile von "subfrmSubtask" und dann verknüpfen mit der "PSTID"?

Hab ich gemacht und ewig rumprobiert mit dem richtigen Filter, also die PSTID ist verknüpft und aktualisiert sich auch. Aber ich nehme an ich brauche in der Datensatzherkunft einen Filter, dachte eigentlich ich füge das Feld
PstRoles_PSTID_F ein und als "kriterien" die PSTID, damit über diese abgeglichen wird, aber das war falsch und auch andere Wege haben leider nicht geklappt.

Unten mal meine Datensatzherkunft, vielleicht ist da ein Fehler

DF6GL

Hallo,

Aber ich nehme an ich brauche in der Datensatzherkunft einen Filter, dachte eigentlich ich füge das Feld


nein!


Ich habe mehrmals gesagt, dass die Formulare sich auf die entspr. Tabellennamen beziehen sollen.

Nimm "tblProSubTaskEquip" als Datenherkunft und stelle die Eigenschaften "Verknüpfen von/nach" auf die Schlüsselfelder ein (Von: "PstWquip_PSTID_f"  , Nach : "PSTID")



dann werden die Equipments von demjenigen DS angezeigt, der im übergeordneten Form markiert(!) ist.




Andi123x4

Ja so hatte ich es ja zuerst, aber ich glaube ich habe dich falsch verstanden gehabt.
Das UFO im Formularfuß muss auch ein Endlosformular sein, oder ?
Weil aktuell ist es ja ein Einzelformular und ich wollte das Listenfeld auf diese weise filtern wie du gesagt hast.
Aber eigentlich müsste ich wohl aus dem UFO ein Endlosformular machen und dann selbiges Spiel wie bei Tasks und Subtasks, ist das der Fehler ?

DF6GL

Hallo,

ZitatDas UFO im Formularfuß muss auch ein Endlosformular sein, oder ?


selbstredend, es sollen doch mehrere DS abgezeigt werden, oder nicht?

ZitatWeil aktuell ist es ja ein Einzelformular und ich wollte das Listenfeld auf diese weise filtern wie du gesagt hast.

Sprich mal Klartext, nenne den genauen Formularnamen.

Und Listenfelder sind doch längst abgeschafft in diesem Zusammenhang  .. ?? Habe ich im letzten Post ausführlich erklärt.



Zitatund dann selbiges Spiel wie bei Tasks und Subtasks,

ja, prinzipiell genau so.  Probier die Sachen doch mal selber aus.