ToDo - Liste im Formular

[atom007]

Hallo,

ich wusste nicht, dass gleichzeitig auf einer anderen Plattform eine ähnliche Frage gestellt hat. Sonst hätte ich mich evtl. dort eingeklinkt und meine Fragen gestellt.
Was die Indizierung betrifft: Erstelle einfach einmal eine Tabelle, Primärschlüssel auf ID. Jetzt erstelle manuell ein paar Einträge.
Lösche die gerade erstellten Einträge. Versuche jetzt manuell nochmal die ID "1" zu erstellen. Geht nicht.
Jetzt mach das selbe Spiel über vba. Dort kannst du hundertmal die ID "1" wieder vergeben. Voraussetzung ist nur, dass die ID "1" in dem Augenblick nicht in der Tabelle ist. Und es gibt noch mehr ähnliche Wege den Index auszutricksen. - Soviel zum Thema Indizierung.

Was Franz angeht: "Schau in der Hilfe nach" ist nicht wirklich der freundliche Weg. Gerade er als Admin könnte einem, der nach Hilfe fragt einfach auch einmal kurz sagen wie was zu tun ist. Positiv war der Tip darunter "Dcount()", dafür habe ich mich auch bedankt...

Was dich betrifft: Vielen Dank für deine Hilfe! Ich habe zwar inzwischen selbst den Weg gefunden um die neuen Einträge erstellen zu können (AddNew) aber genau das war das, was ich noch gesucht hatte.
Jetzt habe ich eine Tabelle "tbl_Aufgaben" die als Puffer dient, bis die Aufgaben erledigt werden. Mit Erledigung werden sie in die "tbl_Erledigte_Aufgaben" verschoben, die Aufgaben-Tabelle ist dann wieder bereit eine neue Woche aufzunehmen.

[MzKlMu]

Hallo,
mit der Indizierung sagst Du mir nichts neues. Du hast das mit der Indizierung auch nicht richtig verstanden.
Es gibt 3 Arten von Indizes:
- Index über ein Feld der Duplikate zulässt. Hier kannst Du eine Zahl beliebig oft eingeben. Erlässt ja Duplikate zu. Ein solcher Index dient dazu Sortierungen und Suchen erheblich zu beschleunigen. Ein solcher Index ist nicht eindeutig, aber es ist ein Index.

- Index über ein Feld der keine Duplikate zulässt. Hier lässt sich ein Wert nur 1x verwenden. Ein solcher Index ist meist der Primärschlüssel, können aber auch andere Felder sein. Z.B. legt man auf die Personalnummer einen eindeutigen Index und über die Nachnamen einen uneindeutigen (Duplikate =Ja) Index. Müller kann es ja mehrfach geben. Bei großen Datenbeständen ist der Index über den Nachnamen wegen des bereits erwähnten Suchen und Sortieren sehr vorteilhaft. Ein solcher eindeutiger Index kann nicht ausgetrickst werden, das wird in der Tabelle zuverlässig verhindert.

- Eindeutiger Mehrfeld Index. Für einen solchen Index werden über mehrere Feld ein zusammengesetzter Index angelegt. Ein solcher Index ist in Kombination der Felder eindeutig.
1 und 1 geht
1 und 2 geht
1 und 1 noch mal geht nicht.

Der zusammengesetzte eindeutige Index ist das was Du brauchst. Und zwar über das Schlüsselfeld vom Mitarbeiter, das Schlüsselfeld der Aufgabe und das Datum/Woche. Damit ist es schlichtweg ausgeschlossen eine Aufgabe zu einem MA und einem Datum mehrfach zu vergeben. Da gibt es keinen Trick der Welt. Eindeutige Indizes sind das A+O einer Datenbank und nicht manipulierbar.

Jetzt habe ich eine Tabelle "tbl_Aufgaben" die als Puffer dient, bis die Aufgaben erledigt werden. Mit Erledigung werden sie in die "tbl_Erledigte_Aufgaben" verschoben,

Das ist überflüssig. Erledigte Aufgaben werden weggefiltert, bleiben aber in der gleichen Tabelle. Durch das Verschieben zerstörst Du ja die Datenkonsistenz. Wie hast Du das geregelt, dass in den verschoben Aufgaben noch zu sehen ist wer es gemacht hat. In der tbl_Aufgaben sollte ja nur der Fremdschlüssel (Zahl) des MA's stehen ?

[DF6GL]

Hallo,

Schau in der Hilfe nach" ist nicht wirklich der freundliche Weg.

Wenn Du meinen Post liest, habe ich geschrieben:

Schau DAZU (nämlich zu den Aggregatfunktionen) in der VBA-Hilfe nach

Das soll Dir die Anwendungsweise dieser Funktionen erläutern, die Du ja nicht gekannt hast...

lesen sich für mich eher abweisend, als irgendwie positiv

.

Naja, das ist Dein Problem.... Ich finde schon, dass die Access/VBA-Hilfe positiv wirkt, indem sie sogar Code-Beispiele liefert.

Zum Crossposting:  Im angegebenen Link wird exakt die gleiche Grundsituation behandelt. Wenn es denn nicht von dir stammt, dann sicherlich von einem Deiner Mitstreiter. Wie auch immer, das ist nur Nebenschauplatz.

Mit Erledigung werden sie in die "tbl_Erledigte_Aufgaben" verschoben

Ich stehe wie Klaus zu derselben Meinung, dass dies ein Irrweg ist.

[atom007]

Hallo,

Ich habe gerade den kompletten Thread von "oschi" gelesen. Stimmt, sieht wirklich nach Crossposting aus, aber ehrlich: Das bin weder ich, noch ein Mitstreiter von mir. In unserem Team bin ich der einzige, der irgendwas am PC (meistens Access oder Excel) macht.
Okay, vielleicht bin ich wirklich auf dem Holzweg. Ich erkläre mein Ziel nochmal, etwas präziser:
Ich will nur eine Liste in der z.B. Spülen, Trocknen, Polieren, Wachsen usw. steht. Jetzt kann ein MA die Aufgabe, die er erledigt hat abhaken. Das wird in eine Tabelle mit Datum und Username eingetragen. Fertig. Am nächsten Montag passiert das ganz gleiche wieder...
Die Aufgaben sind NICHT an einen bestimmten MA gebunden.
Eine Tabelle tbl_User (Mitarbeiter) existiert bereits, da die DB eigentlich für etwas anderes gedacht ist.
Was ich bei eurer Antwort/Reaktion nicht verstehe ist: tbl_Arbeitsliste (soll evtl. Die Tabelle sein, in der am Ende alle Aufträge, erledigt und nicht erledigt, gespeichert sind. tbl_Aufträge wofür? Um darin insgesamt max 10 Einträge zu machen?
Zusätzlich soll gefiltert werden, um nur offene Aufträge anzuzeigen. Irgendwie klingt das für mich nach einem Unterformular, oder sogar ein Extra-Formular.
Ich wollte das eigentlich über ein Listenfeld in einem bereits vorhandenen Form erledigen (in dem sind keine Datensätze, es ist eine Art Menü).
Das kontrollieren, ob die Datensätze bereits in der Tabelle sind hab ich hinbekommen, ebenso bekomme ich es hin, dass die Erledigten DS gelöscht werden. Was ich jetzt aber scheinbar nicht hinbekomme ist: in der Tabelle tbl_Erledigt wird nur die Zahl aus dem Listenfeld eingetragen, nicht der Text und wer wann darauf geklickt hat.

[MzKlMu]

Hallo,
nein, Du hast es noch nicht verstanden.
Die tbl_Arbeitsliste beinhaltet nur die eigentlichen Arbeiten die zu tun sind. In dieser Tabelle steht kein Datum und kein MA. Nur die reinen Arbeiten (Spülen, Trocknen, Polieren, Wachsen usw.) in je einem Datensatz.

tbl_Aufträge wofür? Um darin insgesamt max 10 Einträge zu machen?

In der Tabelle "tbl_Aufträge" werden die Arbeiten wöchentlich eingefügt, mit einem Datum denn Du willst ja protokollieren wer es gemacht hat. Du brauchst diese Tabelle zwingend, wie sonst willst Du festhalten wer es gemacht hat, die Tabelle tbl_Arbeitsliste kannst Du dazu nicht nehmen.

ebenso bekomme ich es hin, dass die Erledigten DS gelöscht werden.

Zum wiederholten mal, das ist völliger Unsinn (sorry, muss das mal etwas drastischer formulieren). Man verschiebt und löscht keine gültigen Datensätze. Die bleiben wo sie sind. Der verschobene Datensatz hat ja keinen Bezug mehr zu dem der drauf geklickt hat. Daher hast Du nur die Zahl drin stehen. Das ist normal und richtig. Für den Namen bräuchtest Du dann wieder eine Abfrage mit der Verknüpfung zum MA.

Nein, Du braucht auch bei der vorgeschlagenen Umsetzung kein Unterformular. Du brauchst auch kein Listenfeld (wozu auch). Das Formular zeigt die Arbeiten die diese Woche zu erledigen sind und der der es macht bzw. gemacht hat wählt mit einem Kombifeld seinen Namen aus, fertig. Vergangene, erledigte Arbeiten werden weggeblendet, bleiben aber in der Tabelle.

PS:
Du frägst hier um Rat, machst aber völlig unbeeindruckt mit Deinem Konzept weiter. Warum fragst Du dann wenn Du es nicht annehmen willst ?

Wenn Du mir Deine DB mal als Beispiel hier hochlädst, richte ich Dir das mal ein. Aber ich benötige zwingend das MDB Format (Access2003).

[DF6GL]

Hallo,

lös dich mal vom Excel-Denken....


Du brauchst eine Tabelle (tbl_MitarbeiterAufgaben) , in der die einzelnen Aufgaben, Mitarbeiter und das Fertigstellungsdatum , etc. eingetragen werden.


Die Mitarbeiter werden in der Tabelle tbl_Mitarbeiter geführt.
Die (alle möglichen) Aufgaben werden in tbl_Aufgaben geführt.


Die Beziehungen werden etwa so aufgebaut:

tbl_Mitarbeiter    ---1:n---   tbl_MitarbeiterAufgaben  ---n:1---   tbl_Aufgaben





Für alle 3 Tabellen erstellst Du je ein Einzelformular zur Eingabe/Pflege der entspr. Daten.

In tbl_MitarbeiterAufgaben  werden die Anzeigefelder für den Mitarbeiter und die Aufgabe als Kombifelder ausgeführt. Die Kombis erhalten ihre Listenfelddaten aus tbl_Mitarbeiter, respektive tbl_Aufgaben.


Es wird also keine wöchentliche Liste geführt, die abgehakt wird.  Das "Abhaken" wird durch die Tatsache realisiert, dass eine Aufgabe zu einen bestimmten Datum von einem bestimmten Ma in tbl_MitarbeiterAufgaben  eingetragen wird.

[MzKlMu]

Hallo,
@atom007
nur damit keine Missverständnisse aufkommen, Franz hat das gleiche Datenmodell wie mein Vorschlag, nur die Tabellen sind anders benannt.

[atom007]

Hallo Klaus & Franz,

ob ihr es glaubt oder nicht: Ich verstehe euer Prinzip schon.
3 Tabellen sind auch notwendig, ich habe meine tbl_User bisher außer Acht gelassen.
Grundsätzlich bin ich aber ein Freund von VBA und habe deshalb versucht den anderen Weg zu gehen. Nicht nur darum, sondern auch:
Mit eurem Prinzip muss ich die Leute in ein zusätzliches Formular zwingen (zum Bestätigen, dass sie eine Aufgabe erledigt haben), die beiden anderen Formulare (zum Eingeben der Mitarbeiter und zum Eingeben/Editieren der Aufgaben) sind ja eher Admin-Sache.
Ich will einfach so viel wie möglich automatisch von Access erledigt haben.
Der User ist Access bekannt, weil sich jeder über eine UserListe einloggt (mit Passwortabfrage). Hierfür gibt es logischerweise auch eine dazugehörige Tabelle.
Somit fehlen noch 2 Tabellen: tbl_Aufgaben und tbl_Erledigt (heisst bei Franz tbl_MitarbeiterAufgaben.
Diese beiden hab ich auch.
Das Prinzip ist mir auch klar: Ein ganz normales Formular, in dem jeder User die erforderlichen Einträge erstellt. Das ist mir alles bewusst.
Mir widerstrebt einfach nur, dass diese Aktion mal wieder über ein extra Formular ablaufen soll. Öffnet ein MA das Formular nicht, so wird auch mal wieder nichts ausgetragen. Genau das haben wir aktuell auch ohne DB.
Die DB in die ich das integrieren wollte/will muss von jedem MA min. 1mal täglich geöffnet werden. Dort landet der User zuerst in einem Formular, das als Menü dient. Und genau da wollte ich das Feld integrieren, damit es jeder sofort sieht, wenn er einloggt.
Über ein Extra-Formular erreiche ich das nicht.
Somit lande ich bei einem Unterformular. - Ist eine Möglichkeit, wenn es keinen anderen Weg geben sollte.
Darum habe ich an dem ListenFeld gebastelt - Das könnte ich problemlos in das Menue-Formular integrieren.
So würde jeder sofort nach dem Login z.B. in rot sehen, was diese Woche noch zu erledigen ist. Das Eintragen per Klick ist ein Luxus, die Leute sind es gewohnt weil ich das auch an anderer Stelle verwende (Access weiß doch das Datum/Zeit und auch wer gerade in der DB ist).
Wenn ein extra Formular oder Unterformular der einzige mögliche Weg sein sollte, dann werde ich den Weg gehen, aber genau da wollte ich eigentlich nicht hin.
Irgendwo hab ich den Eindruck, wir reden/schreiben manchmal aneinander vorbei, sorry.

[MzKlMu]

Hallo,

Dort landet der User zuerst in einem Formular, das als Menü dient. Und genau da wollte ich das Feld integrieren, damit es jeder sofort sieht, wenn er einloggt.

na und, das kannst Du doch auch mit der vorgeschlagenen Version. Das Formular benötigt aber zwingend einen Bezug zu der Tabelle "tbl_Erledigt", auch bei Deiner Version. Das Feld muss ja gebunden sein, dass die Daten in der Tabelle landen.

Darum habe ich an dem ListenFeld gebastelt -

Was willst Du da mit einem Listenfeld, damit kannst Du keine Einträge machen. Ein Listenfeld holt seine Einträge aus bestehenden Daten, da kann nichts geändert werden.

Dort landet der User zuerst in einem Formular, das als Menü dient.

Hat dieses Formular eine Datenherkunft, das heißt, zeigt es Daten aus Tabellen an ?

Irgendwo hab ich den Eindruck, wir reden/schreiben manchmal aneinander vorbei, sorry.

Das sehe ich nicht so.

[Beaker s.a.]

Hallo atom,
Zu deinem Problem von wegen "Austragen vergessen".
Es ist ja in den meisten Fällen doch wohl so, dass der MA morgens/zu Schichtbeginn
eher noch nicht weiss, welcher Aufgaben er den Tag über erledigt. Es gibt ja, wenn
ich es recht verstanden habe, nur allgemeine Aufgaben, die jeder erledigen kann.
Falls sich die MA bei Schichtende wieder ausloggen müssen (zwingend bei einer
Arbeitszeiterfassung), würde ich zu diesem Zeitpunkt das Aufgaben-Formular öffnen/
anzeigen, und ohne Bestätigung das Logout verhindern.
Daten- und Formdesign wie von Klaus vorgeschlagen.
gruss ekkehard

P.S.: Ich habe mal so eine Aufgabenverwaltung für fest zugeteilte Aufgaben erstellt.
Da wurde schon beim Login geprüft ob der MA offene Aufgaben hat, und ggfls. das
zugehörige Form geöffnet bzw. ein Button eingeblendet, mit dem er es selber öffnen
konnte.

[DF6GL]

Hallo,

ich glaube, wir reden nicht aneinander vorbei, wie sehen die Sachlage nur von zwei Perspektiven aus...

Unser Sicht bezieht sich (zunächst) auf die Basis der DB , soll heißen die Datenbeziehungen.

Deine (atom007)  Sicht liegt auf der Datenverarbeitung, bzw. dem Bedienungsablauf der Anwendung.


Wenn zuerst auf die Bedienung geachtet und die Datenkonstellationen zurückgestellt werden,  führt das in den meisten Fällen zu Konflikten bis hin zum Aussortieren der DB  ("in die Tonne" werfen).


Erst wenn  die Datenbasis (unter Beachtung der örtlichen Voraussetzungen)  stimmt, kann anschließend der Bedienungsablauf in die Zwänge geschoben werden, die die Arbeitstätigkeiten am Einsatzgebiet der DB erfordern.

[crystal]

Hallo atom007,

zunächst einmal muss ich den anderen prinzipiell Recht geben, denn erst wenn das Datenmodell stimmt, sollte man sich an die Gestaltung der Oberfläche machen. Aber Access verleitet nunmal eher dazu, es anders herum zu machen...

Zu deiner Vorstellung eines einfachen Listenfelds im Start-Formular:

1. Listenfelder feuern Events wie Klick oder Doppelklick.
2. Ein Listenfeld hat eine Datenquelle (z.B. eine Abfrage) und 1 bis mehrere Spalten, deren Breite auch 0 (unsichtbar) sein kann.
3. Wenn du nun deinem Listenfeld eine Datenquelle wie
select ... from ... where erledigt=false
verpasst und
4. im Klick- oder Doppelklick-Ereignis eine Prozedur schreibst, die das Feld "erledigt" mit
update ... set erledigt=true where key = <Wert aus Listenfeld>
auf true setzt und dann
5. ein Listenfeld.requery machst, ist
6. der Eintrag im Listenfeld weg.

So einfach könnte es gehen und an der Oberfläche aussehen. Du musst die Logik nur in die Klick-Prozedur stecken. Ob du die Aufgabe dort löschst oder nur auf erledigt setzt, ist dann deine Sache.

Ich hoffe, dir mit diesem Hinweis etwas zu helfen.

lg
crystal

UND: was andere gemeint haben, ist ja absolut nicht abwegig.

Wenn du in deinem Start-Formular statt eines Listenfelds ein Unterformular einbaust, in dem es ein "erledigt-Feld" gibt, ist es für den Anwender natürlich auch nicht schwerer, das "erledigt-Feld" anzuklicken (Häkchen) UND das hätte den Vorteil, dass du dieses Kennzeichen NICHT per VBA setzen musst - Access macht das dann nämlich automatisch.

Egal, welche Variante du bevorzugst - hier die Vor- und Nachteile:

Listenfeld:
v: sieht schön kompakt aus
n: User klickt Zeile an, die dann plötzlich verschwindet
n: Du musst selbst VBA-Code schreiben, der die erwartete Funktionalität bereitstellt

Unterformular
v: "erledigt-Feld" bleibt sichtbar (und könnte ggf. auch einfach zurückgesetzt werden)
v: kein VBA-Code erforderlich
n: eher keiner

[atom007]

Hallo,

ich fasse mal kurz zusammen:
Eine Datenbank muss im Aufbau stimmen. Passt.
Die Beziehungen der Tabellen zueinander müssen auch erstellt werden. Passt auch.

Das habe ich doch längst erledigt. Meiner Meinung nach sollte sich niemand an Access heranwagen, der diese Prinzipien nicht weiß oder versteht.

Jetzt zu meinem Thema:
Crystal, dein Beitrag ist super! Genau das meinte ich die ganze Zeit.
Vielen Dank auch an Klaus! Das Angebot mit der MdB ist voll nett, ich habe aber längst verstanden worum es euch geht. Es ist für mich auch kein Problem solch ein Formular zu erstellen, nur will ich das nicht wenn es sich irgendwie vermeiden lässt.
Auch Danke an Franz. Aber der Aufbau der Tabellen ist längst erledigt, es geht um die Eingabe.
Und auch Danke an Beaker, wenn ich es nicht anders hin bekomme werde ich zu deinem Modell greifen!

Mein Denken ist scheinbar für manche Leute absolut schwierig:
Wieso soll ein Benutzer seinen Namen selbst eintragen, wenn das doch Access auch kann? (Wie gesagt, es ist eine DB mit LogIn) - Wieso soll er das aktuelle Datum eintragen, wenn auch das von Access erledigt werden kann?
Wieso ein extra Formular, wenn eigentlich nur ein einziges Feld benötigt wird?

@Crystal: Ich sehe das als Vorteil, wenn eine "offene" Aufgabe verschwindet nachdem sie als "erledigt" gekennzeichnet wurde. Denn dann ist es ja keine "offene" Aufgabe mehr. - Das mit dem VBA-Code ist ein Kriterium, aber wenn ich es lösen kann, dann haben beide Seiten gewonnen... 
Außerdem verleitet ein weiterhin sichtbarer Eintrag dazu geändert zu werden. Ich müsste also alle erledigten Einträge sicher sperren...

Ach ja und noch an Klaus:

Was willst Du da mit einem Listenfeld, damit kannst Du keine Einträge machen

Doch, über vba bei Klick ist das sehr leicht möglich.
Und:

Ein Listenfeld holt seine Einträge aus bestehenden Daten, da kann nichts geändert werden.

Es kann nur bei den Daten, die im Listenfeld angezeigt werden nichts geändert werden. Beim holen und weitergeben der Daten ist auch das möglich.
Um auch deine Frage noch zu beantworten:
Ja, das frm_Menue hat bereits eine Verbindung zu einer Tabelle.
Darum würde/wird es evtl. mit einem Ufrm enden, ausser mir fällt noch ein Weg ein...

[crystal]

Hallo atom007,

danke für deine Antwort und deine anerkennenden Worte (nicht nur für mich).

Viele der anderen sind vermutlich Leute, die eine spezielle Ausbildung hinter sich haben, über Datenbank-Theorien sehr gut Bescheid wissen, und das ist ja auch gut so.

Ich bin im Gegenteil dazu ein Mensch der Praxis und habe mir schon immer besonders Gedanken zur ergonomischen und intuitiven Gestaltung der Oberfläche gemacht. Den Code dahinter kann man kompliziert machen, aber nicht die Oberfläche, denn sie soll möglichst einfach zu bedienen und zu verstehen sein.

Ich verstehe es als das, was ein Programmierer leisten sollte: den Anwender vor für ihn zu komplizierten Abläufen zu bewahren und besser die "Intelligenz" dahinter zu verstecken. Er kennt interne Strukturen und weiß, wie er mit Daten "jonglieren" muss. Seine Aufgabe ist es, die Logik zu programmieren und deren Einhaltung nicht in die Verantwortung der Anwender zu verschieben, um sich das Leben einfacher zu machen.  Mit dieser Auffassung bin ich hier allerdings auch schon öfter heftig kritisiert worden.

Gerne will ich dich bei deinem Vorhaben unterstützen und eine kleine Beispiel-DB basteln mit einem funktionierenden Haupt-Formular, sofern du daran Interesse hast. Schick mir bitte ggf. eine PN.

Ich war früher maßgeblich an der Entwicklung und Anwendung eines Datenbanksystems für Labor und Qualitätskontrolle beteiligt. Meine Rolle war die des Vermittlers zwischen Anwender und Programmierer und ich musste oft viel Überzeugungsarbeit bei letzteren leisten und konnte sehr viel zur Ergonomie des Systems und dessen Akzeptanz beim Anwender beitragen.

Insofern verstehe ich deinen Anspruch wirklich sehr gut, aber durchaus auch die Standpunkte der anderen, die eben eher von der Seite der (akademischen) Datenbank-Theorie denken. Aber diese Standpunkte hast du ja inzwischen auch verstanden und dein Datenmodell entsprechend nachgebessert. Damit erst ist die Basis gelegt, sich an der Oberfläche "auszutoben" - das darf man nicht vergessen.

lg
crystal

[MzKlMu]

Hallo,
@atom007
Wenn das Datenmodell stimmt, macht man sich an die Eingabe. Und wie die Eingabe zu erfolgen hat, darüber wurde ja noch gar nichts abschließendes gesagt. Wenn das Menüformular bereits an eine Tabelle gebunden ist, so ist ja noch lange nicht raus, dass auch die Daten die Du gerne sehen willst angezeigt werden können. Das hängt von der Tabellenstruktur ab.
Bezüglich Listenfeld:
Die Daten eines Listenfeld können definitiv nicht direkt bearbeitet werden, auch nicht mit VBA. Du kannst per Klick auf das Listenfeld die Datengrundlage des LF in einem extra Formular bearbeiten oder Du übergibst den angeklickten DS an ein Recordset zur Anzeige. Ist aber alles viel zu aufwendig.

Wieso soll ein Benutzer seinen Namen selbst eintragen, wenn das doch Access auch kann? (Wie gesagt, es ist eine DB mit LogIn)

Es hat niemand gesagt, dass man das nicht automatisch machen kann. Wenn über das Login der Name bekannt ist, kann man das selbstverständlich automatisieren. Das Gleiche gilt auch für das Datum. Eintragen steht hier als Synonym für das Füllen eines Feldes, egal wie.

Wieso ein extra Formular, wenn eigentlich nur ein einziges Feld benötigt wird?

Weil dieses Feld einen Bezug benötigt zu 2 Tabellen, zum Ausführenden und zur Aufgabe. Du kannst ja nicht einfach ein Feld auf dem Formular platzieren, die Daten müssen ja in den richtigen Tabellen landen. Egal, ob das jetzt manuell passiert oder automatisch ist erst mal egal. Womit wir wieder bei dem Ufo wären.
Daher wäre es mal interessant, welche Daten im Menüformular angezeigt werden.
Kannst Du mal ein Bild dieses Formulars zeigen ? Und zeige bitte mal ein Bild des vollständigen Beziehungsfensters.
Und ein Unterformular ist bei 1:n Beziehungen die beste Methode. Was stört Dich daran ?
Ein Unterformular ist fest mit dem Hauptformular verknüpft und kann so gestaltet werden, dass der Anwender das gar nicht erkennt.