Hallo ich funktioniere diese Thread einfach in mein neues Problem um, wenn auch leider nicht im ganz richtigen Forum.
Also, ich habe im 1. Endlosformular eingestellt das ich keine Duplikate (im Abfrageentwurf der Datensatzquelle) haben will, das Problem ist, dass ich jetzt aber nicht mehr wie sonst, in der untersten Zeile einen neuen DS anfügen kann.
Gibt es da einen Trick, oder muss ich mir ein Behelfsformular bauen, womit ich mit einer Anfügeabfrage der Tabelle, worauf sich das Endlosformular bezieht, hinzufügt?
Evt. lässt sich das auch anders lösen, hier mal der Aufbau
tblDienstkleidungMitarbeiter, tblDienstkleidung, tblMitarbeiter ->
HF -> MitarbeiterID...
1. Endlosformular -> FMitarbeiterID, DienstkleidungID, Dienstkleidungsname
im Fuß 2. Endlosformular -> FMitarbeiterID, FDienstkleidungID, Anzahl, Ausgabedatum
verknüpft 2 zu 1: DienstkleidungID zu FDienstkleidungID und FMitarbeiterID zu FMitarbeiterID
verknüpft 1 zu HF: MitarbeiterID zu FMitarbeiterID
Hallo,
eine Distinct-Abfrage ist grundsätzlich nicht aktualisierbar, es gibt auch keinen "Trick", außer den, den Tabellen-, bzw. Formularaufbau kritisch (und logisch) zu überdenken und die Normalisierungsregeln anzuwenden..
Eine konkrete Aussage könnte anhand des Beziehungsfensters (als Screenshot hochladen) gemacht werden.
Ok hier mal die relevanten Ausschnitte.
1x vom Beziehungsfenster
1x vom Formular, um den Mechanismus besser zu verstehen.
Ziel ist es:
Im Formularkopf wählt man den DS aus, im Detailbereich sieht/soll man NUR die Dienstkleidung sehen die schon zugewiesen ist/wird, als Übersicht (später soll hier noch eine Summe der jeweiligen Sparte stehen), im Fuß wird dann die Detailansicht dargestellt zu dem jeweiligen Dienstkleidungsposten.
Zur Zeit ist es so, dass wenn ich im Fuß zwei mal z.B. T-Shirt auswähle (jeweils als einzelnen DS), dann bekomme ich auch "ohne die select distinct" Variante im Detailbereich 2x T-Shirt angezeigt (ist ja logisch, da ich mich auf die gleiche tabelle beziehe)
Es sollen im Detailbereich die einzelnen Dienstkleidungsposten auswählbar sein und hinzufügbar, aber nur 1x angezeigt pro Dienstkleidungsart und im Fuß die ganzen Detailinformationen angezeigt werden.
Danke schonmal für Anregungen das besser zu machen.
[edit]
hab nochmal die Verknüpfungsfelderdarstellung hochgeladen
[/edit]
Jetzt wo ich mal drüber geschlafen habe, kam mir die Idee einfach eine zusätzliche Tabelle zu machen, in dem jede Dienstkleidung einmalig Mitarbeiter zugeordnet wird/werden kann und diese Tabelle wird dann mit der jetzigen TblMitarbeiterDienstkleidung verknüpft.
Hallo,
Zitatkam mir die Idee einfach eine zusätzliche Tabelle zu machen,
das ist mit Sicherheit der falsche Weg.
Trotz Bilder habe ich den Formularaufbau nicht richtig verstanden.
Aber über das Datenmodell sollte auch nachgedacht werden.
Ausgabe und Rückgabe der Kleidung sollte in je einem Datensatz erfasst werden und nicht Ausgabe mit Meng + und Rückgabe mit Menge -, dann hat man über die Summe automatisch was der Kollege noch hat.
Und wenn Du das Lager als Person führst (ID=0 z.B.) so hast Du ganz nebenbei noch eine komplette automatische Bestandermittlung.
Kannst Du mal eine Beispieldb hier hochladen. Ich benötige aber Access2003 (MDB).
Hallo,
neben dem Vorschlag von Klaus:
Zitat
dass wenn ich im Fuß zwei mal z.B. T-Shirt auswähle (jeweils als einzelnen DS), dann bekomme ich auch "ohne die select distinct" Variante im Detailbereich 2x T-Shirt angezeigt (ist ja logisch, da ich mich auf die gleiche tabelle beziehe)
Es ist eben falsch, zweimal die gleiche Kleidung zuzuweisen und muss verhindert werden....
Setze in der Tabelle tblMitarbeiterDienstKleidung einen zusammengesetzten eindeutigen Index auf die Felder FMitarbeiterID und FDienstKleidungID..
Zusätzlich könnte das Auswahlkombi für die Dienstkleidung so eingestellt werden, dass es nur die noch nicht für den jeweiligen Mitarbeiter ausgegebene Bekleidung anbietet.
Ich lade nachher mal eine Beispieldatei hoch, kann aber Mittag werden.
Ich muss leider gestehen, dass ich ich mit diesen Indizen/indexen noch nie gearbeitet habe und auch nicht ganz verstehe was die genau bringen. Dachte immer zur Suchgeschwindigkeitsoptimierung, aber da steckt ja noch mehr hinter.
Was genau passiert wenn ich den zusammen setze?
Danke!
Hallo,
ein eindeutiger zusammengesetzter Index bewirkt das die Kombination aus FMitarbeiterID und FDienstkleidungID nur 1x geben kann. Das kann hier aber meiner Meinung nach nicht verwendet werden, da das gleiche Kleidungsstück in der Zuordnungstabelle ja mehrfach auftauchen wird, da es ja den Zugang mehrfach geben kann.
Du solltest über eine Änderung des Datenmodells wie oben vorgeschlagen nachdenken.
Ah ok, danke
Hier mal die Bspdatei als .zip komprimiert. Kompatibel mit 2003
Bitte mit Shift starten, hab da glaube noch ne kleine Menüausblendung aktiv.
Hallo,
da gibt es einiges dazu zu sagen.
Die Stammdaten der Person gehören nicht auf ein Register, sondern direkt ins Formular. Dann siehst Du auch immer die Person.
Weiterhin ist für die Daten der Dienstkleidung kein weiteres Formular notwendig, das kannst Du direkt im Detailbereich des Ufos darstellen und auch auswählen.
Außerdem würde ich das ohnehin wie vorgeschlagen machen, für jede Kleidungsveränderung einen eigenen Datensatz.
Dann wäre auch noch das Datenmodell zu verbessern.
Was machst Du, wenn noch ein Löschzug 46 dazu kommt, ein neues Feld ?
Das wäre ja furchtbar, hast Du mal überlegt was Du da alles ändern musst ?
Die Löschzugzuordnung ist n:m genau wie die Kleider.
Auch die Feuerwehrzugehörigkeiten ist n:m.
Dann kannst Du auch gleich ein Datum für die Historie mit erfassen.
Auch der Dienstgrad ist n:m. Dann kannst Du (und nur dann) wer von wann bis wann welchen Dienstgrad hatte.
Insgesamt, fehlen hier noch eine ganze Latte von Tabellen.
- Dienstgrade
- Dienstgradzuordnung (n:m)
- Löschzug
- Löschzugzuordnung (n:m)
- Berufe
Die n:m Tabellen kommen dann in einem Ufo auf eine Registerseite (wie die Kleider).
Wahrscheinlich noch mehr.
Ah ok danke für den Input. Das mal ein Löschzug dazu kommt, hab ich nie so dran gedacht, aber man weiß ja nie was die Zukunft so bringt.
Eine Frage zur Dienstkleidung im Ufo. Das Problem was ich dabei habe ist, dass ich für jedes einzelne Kleidungsstück ein Ausgabedatum brauche, was ja wieder rum bedeutet, dass ich nicht alle "Kategorien" pro Mitarbeiter in einem DS mit Aus-/Rückgabe darstellen kann?!
[Edit]Ich verstehe das so, dass ich dann bei Mitarbeier x für jeden Kleidungsstück einen DS für nen Zugang und einen für nen Abgang habe, heißt ich hab die komplette Historie von ihm dargestellt, was super ist, aber unübersichtlich. [/edit]
Die anderen Tipps werd ich umsetzten, danke
Mal ne Grundsatzfrage nebenbei, wenn ich Daten mithilfe einer Abfrage darstelle, die auch m:n Beziehungen wieder spiegelt, kann ich diese Daten ja in der Regel nicht bearbeiten, sondern nur angucken. Erzeugt ihr euch dann für die Felder die nicht bearbeitbar sind eine Eingabemaske, die dann seperat aufgerufen wird um dort nen Eintrag zu machen?!
Das ist nämlich das Problem was bei mir oft auftritt, wenn ich mit m:n Beziehungen arbeite.
Sprich ein Formular zum Anzeigen und eins zum Daten eingeben.
Hallo,
Zitat
.....da es ja den Zugang mehrfach geben kann
In diesem Fall ist, wie von Klaus angemerkt, der eindeutige Index nicht geeignet....
n:m- Auflösung:
siehe http://dbwiki.net/wiki/Access_Design:_m:n-Beziehungen_aufl%C3%B6sen
Hallo,
Zitatwenn ich Daten mithilfe einer Abfrage darstelle, die auch m:n Beziehungen wieder spiegelt, kann ich diese Daten ja in der Regel nicht bearbeiten, sondern nur angucken
das ist ein weit verbreiteter Irrtum.
Selbstverständlich lassen die Daten in einer solchen Abfrage bearbeiten, völlig problemlos.
ok, ich schau mal das ich alle Kleidungsposten einzeln in einem uform erfasse. Mal gucken wie ich die zu Darstellungszwecke filtern kann.
Hallo,
ZitatMal gucken wie ich die zu Darstellungszwecke filtern kann.
warum sollen die gefiltert werden ?
Du brauchst in einem Ufo nichts zu filtern. Zumindest nicht in diesem Zusammenhang.
Weil ich z.B. nur eine Kategorie sehen will (T-Shirts)
Hallo,
ja, dazu ist das Filtern OK. Dazu kannst Du einfach im Kopf des Ufos ein Kombifeld anlegen mit der Kategorietabelle als Datenherkunft. Und mit diesem Kombi kannst Du dann auch filtern.
Das Kombi hat den Vorteil, dass Du (ohne Tippfehler) nur nach bestehenden Kategorien filtern kannst.
Auch dann, ist noch Dateneingabe/Änderung problemlos möglich.
Super
Morgen,
irgendwie klappt mein Filter nicht...
Ich hab eine Combobox im Formularkopf meines Unterformular (wie o.b. mit der Datenherkunft von der Tabelle mit den Kategorien)
Hab auch gebundene Spalte auf 2 gesetzt, damit ich nicht die ID, sondern den tatzächlichen txt bekomme.
Ich habs folgerndermaßen versucht:
Me.Filter = "'" & Me!cmbFilterDienstkleidung & "'"
Me.FilterOn = True
er zeigt keine Fehlermeldung an, aber er macht auch nichts.
dann hab ich
Forms![frmStammdaten]![frmDienstkleidung].Form.Filter = "'" & Me!cmbFilterDienstkleidung & "'"
'Forms![frmStammdaten]![frmDienstkleidung].Form.Filter = "'" & Form_frmStammdaten.frmDienstkleidung!cmbFilterDienstkleidung & "'"
Forms![frmStammdaten]![frmDienstkleidung].Form.FilterOn = True
versucht, geht aber auch nicht. Im Ribbon kann ich sehen, dass der Filter aktiviert wird...
HF Name = frmStammdaten
Name des uFrm Rahmens = frmDienstkleidung
das ganze läuft in einem Registersteuerelement, muss ich da die Seite auch noch einbauen?
wäre SeitenID = 4, Name der Seite = Dienstkleidung
:o
Wenn ich aus dem Ribbon im Formular filtere, klappt das (Accesseigene Filtersteuerelemente)
bei allen Varianten zeigt er mir beim Haltepunkt den korrekten Filtername an, sprich z.B. "T-Shirt - blau"
Danke
Hallo,
ZitatHab auch gebundene Spalte auf 2 gesetzt, damit ich nicht die ID, sondern den tatzächlichen txt bekomme
das ist falsch, gefiltert wird immer über die ID, das ist auch eines der Aufgaben einer ID. Stelle also die gebundene Spalte wieder auf 1.
Die Datenherkunft (Tabelle Kategorien) des Kombis sollte die ID als 1.Spalte und die Bezeichnung als 2. Spalte haben.
Kombi wie folgt einstellen:
Spaltenzahl: 2
Spaltenbreiten: 0cm;5cm (die 1.Spalte wird ausgeblendet, Spalte 2 ist zu sehen)
Geb.Spalte: 1
Steuerelementinhalt: Nix (ungebunden)
Im Ereignis "Nach Aktualisierung" des Kombis folgenden Code:
Me.Filter = "KategorieID = " & Me!cmbFilterDienstkleidung
Me.FilterOn = TrueKategorieID ist der Name des Fremdschlüssels für die Kategorie in der Tabelle mit der Kleidung. Eventuell anpassen.
PS:
Ich verstehe nicht, warum man immer nur Codeschnippsel zeigt.
Bitte immer die vollständige Prozedur (mit Kopf und Fuß) zeigen, damit man auch die Zusammenhänge komplett sieht.
Ah ok, Kritik angenommen.
Danke für die Korrektur, ich musste mich beim Filtern auf ein Filterfeld beziehen...
Hallo,
Du solltest auch die anderen Hinweise beachten, gefiltert wird grundsätzlich mit der ID.
ja hab ich.
Danke