Hallo zusammen,
ich möchte gerne eine ToDo-Liste in ein Formular einbauen.
In der Liste sollen wöchentlich ca. 5-10 Aufgaben eingetragen sein, die dann einzeln durch verschiedene Benutzer ausgetragen werden.
Mein Problem ist: Bevor ich anfange irgendwas zusammen zu semmeln, wie baue ich so etwas sinnvoll auf und wie bekomme ich Access dazu, die Aufgaben wöchentlich selbst neu zu erstellen?
Hat jemand so etwas schon mal probiert oder evtl. Erfahrung mit ToDo-Listen?
Thx schonmal für die, die mir eventuell helfen können!
Hallo,
bevor Du Formulare "zusammen semmelst", mach Dir Gedanken um die Daten, die für die Bearbeitung solcher "ToDo-Listen" (was ist da Besonderes dran) nötig und welche schon vorhanden sind.
Lt. der Beschreibung sind (mindestens) erforderlich:
tblMitarbeiter
MAID (PK, Autowert)
MA_PersNr (Long, bzw. Text)
MA_Vorname (Text)
MA_Nachname (Text)
.
.
.
tblToDo
TDID (PK, Autowert)
TD_MAID (Long, FK zu tblMitarbeiter)
TD_Topic (Text)
TD_Task (Memo)
TD_ErstellDatum (Datum/Uhrzeit)
TD_ErledigtDatum (Datum/Uhrzeit)
TD_ZuErledigenBis (Datum/Uhrzeit)
.
.
.
Evtl. sind weitere Tabellen nötig, z. B. ToDoArten oder "Meilensteine" etc.
ZitatAccess dazu, die Aufgaben wöchentlich selbst neu zu erstellen
??
Woher weiß Access, welche Aufgaben zu welchem Termin zu behandeln sind?
Danke DF6GL für deine Antwort,
ok, die Mitarbeitertabelle (existiert schon) und die ToDo-Tabelle sind soweit kein Problem. Das eigentliche Problem ist eher das, was du am Ende beschrieben hast: "Woher weiß Access, welche Aufgaben zu welchem Termin zu behandeln sind?".
Wann die Aufgaben zu behandeln sind muss Access gar nicht wissen. Es genügt, wenn Access diese Aufgaben jede Woche neu erstellt (und genau das ist momentan noch mein gedankliches Problem).
Das Erledigen machen die Mitarbeiter.
Ich hab mir z.B. eine Listenauswahl vorgestellt, wo der Mitarbeiter, der die Aufgabe abgeschlossen hat einfach durch Doppelklick die Aufgabe abschließt.
Hallo,
werden alle Arbeiten wöchentlich ausgeführt ?
Und an welchem Tag der Woche ?
Wie erfolgt die Aufteilung der Arbeiten, welcher Mitarbeiter macht was ?
Hallo MzKlMu,
ja, alle Aufgaben müssen im Lauf der Woche abgeschlossen werden.
Der Tag der Woche ist egal, wichtig ist nur daß die Aufgabe abgeschlossen wird.
Ebenso gibt es keine Vorgabe der Mitarbeiter, weil "rotierendes Personal". Die Mitarbeiter wissen eigentlich, was zu tun ist, aber es wurden ab und zu Einzelteile vergessen, darum will ich die ToDo-Liste einbauen.
Jede Woche Montag Morgen muss die Liste neu erstellt werden und dann bis Freitag abgeschlossen sein.
Hallo,
dann sind mal mindestens 3 Tabellen erforderlich.
- Mitarbeiter
- Arbeitsliste
- Aufträge
In der Tabelle Aufträge gibt ein Fremdschlüsselfeld zum MA, ein Fremdschlüsselfeld zur Arbeit und ein Datum.
Du kannst dann z.B. für ein Jahr im Voraus per Anfügeabfrage für jede Woche (mit Datum für Mo z.B.) je einen Datensatz aus der Arbeitsliste anfügen. Das Feld für den MA bleibt leer und wird später mit einem auf die Woche gefilterten Formular per Kombifeld aus der Mitarbeiterliste ausgewählt.
Hmmm....
sorry, aber das ist weniger die Lösung an die ich eigentlich dachte.
Mein Gedanke war eher über vba abzufragen, ob heute Montag ist, wenn ja, dann die Tabelle abfragen ob die Einträge schon erstellt sind und wenn nicht, dann sollen die Einträge in die Tabelle geschrieben werden. Dort werden sie dann von den MA nach Erledigung angeklickt und somit über eine Abfrage in eine Speicher-Tabelle geschrieben. Somit wäre jede Woche zu sehen, welche Aufträge aktuell sind und noch erledigt werden müssen. Wenn in der Tabelle Einträge der kommenden Woche zu sehen sind, dann könnte es zu Irreführungen kommen (meine ich).
Hallo,
Du denkst falsch, mein Vorschlag ist nichts anderes als das was Du vorhast.
ZitatWenn in der Tabelle Einträge der kommenden Woche zu sehen sind, dann könnte es zu Irreführungen kommen (meine ich).
Da irrst Du, wie ich oben schon geschrieben habe, wird das Formular auf die gewünschte Woche gefiltert, dann sieht man immer nur die gewünschte Woche. Das lässt sich auch so einstellen, dass nur die aktuelle Woche angezeigt wird.
ZitatDort werden sie dann von den MA nach Erledigung angeklickt
Das anklicken ist nicht notwendig. Da es egal ist wer es macht, wird einfach per Kombi der Name gewählt der die Arbeit gemacht hat. Damit ist die Arbeit auch ohne Haken als erledigt gekennzeichnet.
Ok, ich habe jetzt die Tabellen erstellt, allerdings lasse ich die Aufgaben-Tabelle leer. Jetzt werden Montags per vba die Einträge in die Tabelle geschrieben (eine Vorgabe-Tabelle mit den Datum's erstellen erscheint mir unpraktisch, besonders falls irgendwann mal eine Aufgabe dazu kommen sollte).
Im Formular ist jetzt ein Listen-Feld in dem die Aufgaben dann zu sehen sind. Per Klick werden dann die Aufgaben als "Erledigt" markiert und mit Datum/Zeit und User-Daten in die Erledigt-Tabelle verschoben. Das passt soweit.
Jetzt gibt es für mich nur noch 1 Problem: Wie kann ich vor dem Erstellen der Wochen-Einträge in die tbl_Aufgaben kontrollieren ob die Einträge schon da sind um Doppel-Einträge zu vermeiden?
Hallo,
ZitatWie kann ich vor dem Erstellen der Wochen-Einträge in die tbl_Aufgaben kontrollieren ob die Einträge schon da sind um Doppel-Einträge zu vermeiden?
Vermutlich mit einem
eindeutigen Mehrfelderindex (Datum und Aufgabe).
Dabei darf das Datumsfeld aber keine Zeitanteile <> 00:00:00 haben.
gruss ekkehard
Thx Beaker für deine Antwort.
Die Tabelle zu indizieren würde nichts bringen, weil die Einträge über vba kommen.
Ich müsste irgendwie über vb fragen, ob schon was in der Tabelle steht und nur wenn nicht sollen die Einträge neu gemacht werden.
Hallo,
ZitatDie Tabelle zu indizieren würde nichts bringen, weil die Einträge über vba kommen.
Wie kommst Du darauf?
Eine Indizierung hat nichts mit "VBA-Einträgen" zu tun..
ZitatIch müsste irgendwie über vb fragen, ob schon was in der Tabelle steht und nur wenn nicht sollen die Einträge neu gemacht werden.
Dafür gibt es die Domänenaggregat-Funktionen (z. B. DCount(), Dlookup(), etc.).
Schau dazu in der VBA-Hilfe nach.
Hallo
das hier stinkt verdächtig nach Crossposting...
http://www.ms-office-forum.net/forum/showthread.php?t=337103
Thx DF6GL für deine Antwort.
Punkt 1: Ich habe keinen Grund Crossposting zu machen, ich habe hier schon öfters was gefragt und brauche dazu keine 2. Internet-Seite mit dem selben Material zu belasten.
Punkt 2: Ich dachte, ich frage hier Leute, die sich auskennen mal um ihre Hilfe, bzw. Tips & Tricks. Äusserungen wie z.B. "Schau in der VBA-Hilfe nach" lesen sich für mich eher abweisend, als irgendwie positiv. Dass man in der Access-Hilfe nachschauen kann weiss ich selber, aber vielen Dank für deine Hilfsbereitschaft.
Hallo,
an Grossposting habe ich im andern Forum auch gedacht, war mir aber nicht sicher, daher habe ich nichts gesagt.
Der Hinweis von Franz auf die Hilfe hat mit abweisen nichts zu tun. In der Hilfe gibt es oft ausführliche Beispiele zu Befehlen. Mindestens so viel wie man hier schreiben kann. Daher war der Hinweis auf die Hilfe durchaus angebraucht und bringt Dich auch weiter.
Was die Indizierung betrifft, so bringt die natürlich was. Eine Indizierung verhindert bereits auf Tabellenebene zuverlässig die Entstehung von Doppelungen, dabei ist es völlig unerheblich wo die Daten herkommen. Ob VBA oder manuell spielt also keine Rolle.
Wenn man die Datensätze per Recordset über AddNew anfügt werden bei einer Indizierung automatisch nur die DS angelegt die es noch nicht gibt.
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.
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.
ZitatJetzt 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 ?
Hallo,
ZitatSchau in der Hilfe nach" ist nicht wirklich der freundliche Weg.
Wenn Du meinen Post liest, habe ich geschrieben:
ZitatSchau 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...
Zitatlesen 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.
ZitatMit Erledigung werden sie in die "tbl_Erledigte_Aufgaben" verschoben
Ich stehe wie Klaus zu derselben Meinung, dass dies ein Irrweg ist.
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.
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.
Zitattbl_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.
Zitatebenso 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).
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.
Hallo,
@atom007
nur damit keine Missverständnisse aufkommen, Franz hat das gleiche Datenmodell wie mein Vorschlag, nur die Tabellen sind anders benannt.
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.
Hallo,
ZitatDort 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.
ZitatDarum 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.
ZitatDort 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 ?
ZitatIrgendwo hab ich den Eindruck, wir reden/schreiben manchmal aneinander vorbei, sorry.
Das sehe ich nicht so.
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.
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.
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
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:
ZitatWas 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:
ZitatEin 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...
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
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.
ZitatWieso 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.
ZitatWieso 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.
Hallo,
Ich glaube ich bekomme es so hin, wie ich das gerne möchte. Hab inzwischen per Google ein paar Möglichkeiten gefunden, die sich als positiv erwiesen haben.
Crystal spricht mir aus dem Herzen! Toll, dass es hier auch solche Leute gibt.
@Klaus: Die Beziehungen auf dem Bild sind nur die, die in der temporären DB sind. Ich habe mir zum Aufbauen der neuen Funktion eine Temporäre DB aufgebaut, weil die Original-DB ja in gebrauch ist.
Das Menü-Bild entspricht zu 100% dem Original.
Und dort will ich nach Möglichkeit UNTEN im Menü-Formular die "Offenen Aufgaben der aktuellen Woche" haben.
Hallo,
ich darf Dich mal zitieren:
Zitatich 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.
Nix passt. Du hast es auch nicht richtig verstanden. Die Beziehungen sind zu überarbeiten. Beziehungen laufen immer über die Schlüsselfelder, von Primärschlüssel zu Fremdschlüssel. Der zusammengesetzte Primärschlüssel in der Benutzertabelle macht auch keinen Sinn, da die ID für sich schon eindeutig ist.
Wieso nennst Du die Aufgaben in der Aufgabentabelle nun plötzlich Auswahl und in der Erledigttabelle heißt es wieder Aufgabe. Das ist doch unlogisch und außerdem verwirrend. In 4 Wochen weißt Du nicht mehr was Du Dir dabei gedacht hast.
Und nebenbei, auf Leer und Sonderzeichen in Feld und Objektnamen solltest Du konsequent verzichten. Es birgt Fehlerquellen an denen Du unter Umständen lange suchst.
Bevor Du mit Formularen weiter machst, solltest Du erst mal die Struktur in Ordnung bringen.
Siehe Bild.
UPS!
Da ist mir gestern wohl ein Fehler unterlaufen.
Die Beziehungen untereinander hab ich gestern in der Test-DB schnell zusammengesetzt weil ich das Original nicht schicken kann.
Ist aber egal: Ich habe es geschafft!
Ich hab jetzt ein Listenfeld in meinem Menü-Formular. Jeder User, der eine Aufgabe erledigt hat kann sie anklicken, sie verschwindet und wird in eine Tabelle eingetragen. Jede Woche werden die Aufgaben automatisch neu erstellt und sind dann wieder sichtbar.
Und genau das wollte ich!
Zu den Beziehungen noch kurz: Auch wenn es für euch hier der Horror zu sein scheint: Man kann eine Tabelle auch absolut OHNE Beziehung aufbauen und verwenden. Im Rechnungswesen und ähnlichem sind die Beziehungen untereinander absolut wichtig, in einer Mini-Tabelle in der nur Name, Datum und erledigte Aufgabe stehen sind die Beziehungen meiner Meinung nach so wichtig wie ein Kropf.
Wenn ich den Verlauf meiner Bitte um Hilfe durchsehe, dann stelle ich fest dass mir was die Aufgabe angeht nie wirklich geholfen wurde. Ihr habt euch an der Struktur festgebissen und das war's. Nur Crystal hat wirklich verstanden worum es mir ging, toll dass es auch solche Leute hier gibt.
Vielleicht wäre es auch einmal cool, wenn die großen Guru's einfach beim lösen des Problems helfen würden anstatt zu versuchen ihre festgewachsene Meinung über Struktur und Aufbau aufzudrücken.
Man kann auch helfen, indem man auf die Frage eingeht und wenn es Probleme gibt hilft man bei der Lösung des Problems. Wenn ein neues Problem auftaucht, weil die Beziehungen der Tabellen nicht passen kann man auf das Thema eingehen. Wenn das aber gar nicht erforderlich ist, weil (noch) kein Problem existiert, dann ist es schade wenn sich die Leute darauf konzentrieren und das eigentliche Thema außer Acht lassen...
;)
Hallo atom007,
meine Gratulation, dass du es geschafft hast! Ich spüre förmlich, wie froh und stolz du bist, eine schöne einfache Lösung für die Mitarbeiter gefunden und umgesetzt zu haben. Vermutlich werden sie es dir danken.
Vielen Dank auch für dein Lob an mich. Ich werde weiter versuchen, mit lateralem, pragmatischen Denken meinen kleinen Beitrag in diesem Forum zu leisten, auch wenn ich von Profis belächelt oder gar beschimpft werde.
Aber vergesse bitte nicht, dass dir der Weg, den du jetzt zur Lösung beschritten hast, auch von anderen gezeigt wurde, indem sie richtigerweise auf Fehler im Datenmodell hingewiesen haben.
Beste Grüße und weiter viel Erfolg bei der Umsetzung neuer Ideen!
crystal
Hallo,
ZitatWenn ein neues Problem auftaucht, weil die Beziehungen der Tabellen nicht
passen kann man auf das Thema eingehen.
Warum warten? Der frühe Vogel fängt den Wurm ;)
Mit von Anfang an richtiger Struktur würde dieses neue Problem evtl. gar nicht auftauchen.
gruss ekkehard
P.S. Ich betrachte mich absolut nicht als Guru (diese Einstufung des Forums habe ich
schon des Öfteren kritisiert), aber ich hatte das Glück bei meinen Anfängen noch von
den echten Gurus (DonKarl, MZausMZ usw.) lernen zu dürfen.
Hallo,
Beaker, du warst damit auch nicht gemeint, sorry!
Dein Tip war klasse, ich hatte mir nur was anderes vorgestellt. Wie gesagt: hätte ich es nicht geschafft, dann wäre ich mit Sicherheit darauf zurück gekommen. Danke nochmal!
@Crystal: Ich will auch nicht die Moderatoren schlecht machen, ganz sicher nicht. Die Angebote/Beiträge waren in gewisser Hinsicht nett, immer korrekt und eigentlich okay. Aaaber: Auf mein eigentliches Problem wurde niemals eingegangen. Für Franz & Klaus existieren scheinbar nur Strukturen und Beziehungen.
In meinem Modell brauche ich z.B. gar keine Tabelle mit den Aufgaben, denn die kommen aus vba. Und das ist Absicht!
Ob ich als Admin jetzt ein Formular öffne und dort einen DS hinzufüge oder ob ich in vba gehe und das dort mache ist (mir) egal. Die User dürfen dort sowieso nichts ändern, ist komplett gesperrt.
Der Weg, der mir immer wieder und wieder auferlegt wurde ist für mich einfach zu "altmodisch". Access kann so viel, wenn man es wirklich nutzt und da muss ich mich nicht an Modelle aus der Entstehungszeit halten.
;)
Hallo Beaker,
danke für dein PS
ZitatP.S. Ich betrachte mich absolut nicht als Guru (diese Einstufung des Forums habe ich
schon des Öfteren kritisiert), aber ich hatte das Glück bei meinen Anfängen noch von
den echten Gurus (DonKarl, MZausMZ usw.) lernen zu dürfen.
Auch ich empfinde mich nicht als "Access-Profi", nur weil ich hier mehr als x-mal geschrieben habe. Danke also für dein statement - obwohl es aus meiner Sicht eher ein Understatement ist, denn deine Beiträge sind eigentlich immer zielorientiert und hilfreich.
Ich hatte ja schon mal vorgeschlagen, eine Art der Bewertung einzuführen, aber das wurde heftig abgelehnt. Vielleicht ist es an der Zeit, darüber noch einmal nachzudenken. Die "Danke-Funktion" geht ja schon in diese Richtung.
lg
crystal
Hallo Atom,
Zitatda muss ich mich nicht an Modelle aus der Entstehungszeit halten.
Die Grundlagen der Datenmodellierung sind deutlich älter als Access, und haben auch
nicht proprietär mit Access zu tun, die gelten für alle Datenbanksysteme. Die wurden
IMO schon in den 1960ern von einem Herrn Codd und weiteren entwickelt. Weisst doch:
"The key, the key and nothing like the key, so help me Codd!" (oder so ähnlich).
Das ist wie beim Rechnen, wenn du das kleine Ein-mal-Eins nicht verstanden und intus
hast, kannst du auch keine binomischen Formeln oder sonst was "höheres" berechnen.
gruss ekkehard
Hallo,
@atom007
Es geht nicht darum Dir irgendetwas aufzuzwingen. Genau wie Du hier uns vorwirft sich am Datenmodell festzubeißen, könnte man Dir vorwerfen Du lässt Dich nicht von Deiner vorgefertigten Meinung abbringen. Ein korrektes Datenmodell erleichtert auch die Eingabe und die Pflege. Und wenn man das oben hochgeladene Beziehungsbild betrachtet, so kann man hier durchaus der Meinung sein, man muss unbedingt noch mal auf die Grundlagen eingehen. Keine der beiden Beziehungen ist richtig.
Zitatin einer Mini-Tabelle in der nur Name, Datum und erledigte Aufgabe stehen sind die Beziehungen meiner Meinung nach so wichtig wie ein Kropf.
Das ist ein No-Go, egal wie groß die Datenbank ist. Nur mit den Beziehungen mit referentieller Integrität kannst Du die Datenkonsistenz sicherstellen. Und das kann auch in einer kleinen Datenbank sehr wichtig sein. Dieser pauschale Aussage muss als widersprochen werden.
Aber egal, Du hast ja jetzt eine Lösung die Dir gefällt.
@Crystal
ZitatIch hatte ja schon mal vorgeschlagen, eine Art der Bewertung einzuführen, aber das wurde heftig abgelehnt. Vielleicht ist es an der Zeit, darüber noch einmal nachzudenken.
Ich bin schon seit 12 Jahren in Rente und betätige mich hier in meiner Freizeit als Helfer und Moderator. Glaubst Du ernsthaft, ich lasse mich hier bewerten ? Mein Chef hat mich früher bewertet, aber das ist längst vorbei (das hat jetzt meine Frau übernommen, aber die darf das). Nicht das ich Angst davor hätte, aber wie willst Du ehrliche Bewertungen sicherstellen? Soll das jemand kontrollieren, wenn ja wer ? Das Forum kostet den Betreiber nur Geld, wie soll da eine Bewertung moderiert werden (und das müsste es), wer soll dazu die zusätzliche Zeit aufbringen ?
Was macht der Bewertete wenn er ein schlechte Bewertung bekommt, nur weil der andere es nicht verstanden hat oder sich geärgert hat ?
Ich will mich doch nicht auch noch über ungerechte Bewertungen ärgern müssen. Und sage mir nicht, dass die nicht kämen. Was soll ich dann machen, eine Gegenrede schreiben ?
Ich bin in 3 Access Foren zu Gange, ich habe schon PN bekommen die den Straftatbestand der Beleidigung erfüllten. In einem Falle habe ich sogar ernsthaft überlegt Strafanzeige zu erstatten. Es gibt Leute meinen ja das IE ist ein rechtfreier Raum und könnten sich verbale Ausrutscher leisten. Es gab auch schon Leute die sich verbale Ausrutscher direkt in den Beiträgen leisteten, obwohl sie Hilfe wollten. Glaubst Du wirklich es werden nur objektive und ehrliche Bewertungen geschrieben, nie im Leben.
Nein, ich glaube nicht, dass es in diesem Forum Bewertungen geben wird. Keiner der Moderatoren ist dafür. Der Danke Button ist völlig ausreichend.
PS:
Ich lege noch Wert auf die Feststellung, dass meine Klagen nichts mit diesem Thema zu tun haben, da war alles gesittet. ;D
Lieber Klaus,
Ich will das Thema "Bewertung" nicht weiter kommentieren, außer:
niemand sollte hier Personen beurteilen können, sondern nur, ob eine Antwort zielführend und hilfreich war oder nicht. Das ist ja mit der "Danke-Funktion" bereits teilweise so gemacht worden. Es fehlt eigentlich nur noch "Zahl der Dankes" zusätzlich zu "Zahl der Posts".
Natürlich ist es bitter und verabscheungswürdig, wenn sich frustrierte Poster in persönlichen Beleidigungen auskotzen. Aber würde ein simples "Barometer" nicht gerade helfen, das zu verhindern? Würde ein "Daumen hoch" für einen Beitrag nicht ein "Daumen runter" kompensieren, zumal wenn es namentlich erfolgt (wie jetzt das Danke)?
Selbst Microsoft stellt auf vielen Seiten die Frage "War diese Seite hilfreich?"
Wenn ein User vermehrt oder überproportional "Daumen runter" signalisiert, könnte man ja auch Maßnahmen ergreifen und ihn z.B. in einem neuen Unterforum zur Rede stellen.
Letztlich - und das ist hier die entscheidende Aussage - bin auch ich nicht damit einverstanden, hier als Access-Profi eingeschätzt zu werden, nur weil ich eine gewisse Anzahl von Posts geschrieben habe. Denn diese bloße Zahl sagt nichts über die "Qualität" meiner Posts und könnte neue Benutzer sogar in die Irre führen.
Ich persönlich fände es OK, wenn meine Posts von anderen mit Daumen hoch oder runter beurteilt werden würden. Und wenn solche Beurteilungen mit max. 30 Zeichen Text kommentiert werden müssten, oder der Grund aus einer Liste zu wählen wäre, hätten andere die Möglichkeit, dies zu sehen und sich ihr eigenes Bild zu machen bzw. ggf. ihre eigene Meinung entgegenzustellen.
Jetzt jedenfalls kann man aus der Anzahl von Posts in keiner Weise ablesen, wie "gut" die Antworten durchschnittlich waren. Und das finde ich ein bisschen schade.
Soviel zu diesem OT-Thema. Vielleicht können wir die Diskussion im Smalltalk weiterführen.
lg
crystal
Hallo,
Antwort noch mal hier, dann ist das Thema für mich durch.
Auch Daumen hoch/runter ist eine subjektive Bewertung. Auch Beiträge die falsche Lösungen zeigen werden dann mit Daumen hoch bewertet, nur weil es für den Fragenden gerade passt aber andere Lösungen besser wären. Und wenn dann noch 30 Zeichen dazu kommen, haben wir schon das beschriebene Problem mit unsachlichen Bewertungen.
Und was nutzt die Frage "War diese Seite hilfreich?" Was soll das bringen ?
Das ist ja auch wieder sehr subjektiv, der der es verstanden hat sagt ja, der der es nicht verstanden hat sagt nein. Das ist nicht die Spur einer Bewertung. Ob sich bei MS die Klicks jemand ansieht darf auch bezweifelt werden. Ich finde den Danke Button absolut ausreichend. Wenn es mir geholfen hat sage ich danke, wenn nicht lasse ich es. Ich habe 5800 Beiträge in diesem Forum mit "nur" 207 Danke. Ich bin sehr sicher, dass ich mehr als 207 mal geholfen habe. Und die anderen Beiträge waren Schrott ? Was sagt das jetzt jemand der nachsieht, nix. Im Grunde halte ich daher auch den Danke Button für überflüssig.
Du kannst gern im Smalltalk ein Thema dazu beginnen, aber ich weiß noch nicht ob ich mich beteilige.
Hallo,
Also was ich keinesfalls wollte ist hier einen Streit unter den Moderatoren auslösen.
Ich danke allen, die sich die Zeit hier genommen haben mir zu antworten und mir indirekt den einen oder anderen Tip gegeben haben.
@Klaus: Ich habe mich hier nicht von meiner Meinung abbringen lassen, weil ich mir recht sicher war daß mein Ziel erreichbar ist und das hat sich jetzt auch bewahrheitet. In Bezug auf Beziehungen könnte ich mit Sicherheit noch sehr viel von euch lernen aber ich sehe manches aus einer anderen Perspektive und setze für mich deshalb ganz andere Ziele. Das Endergebnis muss passen, auf welchem Weg ich dahin gehe ist eine andere Sache. Es kann der einfache Weg sein, oder auch mal ein anderer. Nur mal 1 Beispiel: vertipp dich in deinem Beziehungsmodell ein einziges mal und du hast u.U. Tausend falsche Rechnungen bzw. Einträge. Vertippe ich mich in einer unabhängigen Tabelle 1 mal, dann ist nur ein DS falsch.
So, ich bedanke mich hiermit nochmal bei allen, die hier manchmal ellenlage Texte hinterlassen haben um mich auf den richtigen Pfad zu bringen und hoffe, falls doch nochmal eine Frage / ein Problem aufkommt auf eure Hilfe.
Thx an alle...
Hallo,
Zitatvertipp dich in deinem Beziehungsmodell ein einziges mal und du hast u.U. Tausend falsche Rechnungen bzw. Einträge.
In den für die Beziehungen relevanten Feldern kann man sich nicht vertippen. Die sieht man nämlich nicht und man kann sich demnach nicht vertippen. Die Fremdschlüsselfelder werden entweder automatisch gefüllt oder per Kombi gewählt. Außerdem ist es bei Beziehungen mit referentieller Integrität gar nicht möglich Datensätze anzulegen zu denen es keine Bezüge zu Feldern gibt die einen Fremdschlüssel speichern. Die Wahrscheinlichkeit für falsche Daten ist bei beziehungslosen Datenbanken deutlich höher.
Falsche, inkonsistente Daten müssen wenn keine Beziehungen angelegt sind, durch eigene aufwendige Programmierung ersetzt werden.
Und das hat gar nichts mit Access zu tun, das sind Regeln die für jedes relationale Datenmodell gelten.
ZitatAlso was ich keinesfalls wollte ist hier einen Streit
Du hast doch keinen Streit ausgelöst, das war ein sachlicher Austausch gegensätzlicher Standpunkte. Das ist normal und auch OK.