Neuer DS im Endlosformular trotz "select Distinct"

[Xoar]

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

[DF6GL]

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.

[Xoar]

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]

[Xoar]

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.

[MzKlMu]

Hallo,

kam 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).

[DF6GL]

Hallo,


neben dem Vorschlag von Klaus:

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.

[Xoar]

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!

[MzKlMu]

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.

[Xoar]

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.

[MzKlMu]

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.

[Xoar]

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

[Xoar]

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.

[DF6GL]

Hallo,

.....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

[MzKlMu]

Hallo,

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

das ist ein weit verbreiteter Irrtum.
Selbstverständlich lassen die Daten in einer solchen Abfrage bearbeiten, völlig problemlos.

[Xoar]

ok, ich schau mal das ich alle Kleidungsposten einzeln in einem uform erfasse. Mal gucken wie ich die zu Darstellungszwecke filtern kann.