Access_Neuling_DomWert mit Datumsvergleich im Kriterium

[DF6GL]

Hallo,

k. A. wie die Felder heißen,  deshalb riet ich letzthin, die Felder (Feldnamen) zu überprüfen.

Habe auch nicht den ganzen Threat durchforstet.

"Wäre MAX da nicht besser?"

dürfte "egal" sein...  Es sollte in dem Datumsbereich ja eh nur einen Wert geben. 

DMAX liefert halt den größten Wert von "Kilometer_Betrag", Dlookup den ersten beliebigen .  Beides wäre falsch, gäbe es mehrere DS.

TOP 1 ist auch nur deshalb eingesetzt, um Jet unmissverständlich zu erklären, dass nur ein DS von der Abfrage geliefert werden wird. Access nimmt das ohne TOP 1 (im Vorfeld) nicht als selbstverständlich an, auch wenn letztendlich und tatsächlich nur ein DS geliefert würde.

[Beaker s.a.]

Hallo Franz,
Danke für Erklärung.
gruss ekkehard

[dschroeder1989]

Guten Abend allerseits,
ich war über das WE auf einer Tagung daher die späte Antwort.
Ich habe eben versucht alle neuen Antworten zu verstehen... leider nicht so ganz
Daher im Anhang die Datenbank, habe aus Datenschutzgründen die Tabellen geleert, sollte aber hoffe ich keine Bezugsprobleme geben. Enthalten ist aktuell nur die Update Variante ohne den benötigten Datumsvergleich dort gespeichert.
Ich hoffe das macht die Sache einfacher.


(und noch als .mdB, ist das vollständig abwärtskompatibel mit Access 2016?)


>Viele Grüße und vielen Dank
David

PS: Da die Dateien größer als 300 KB , per Link

Links gelöscht, wegen Virenwarnungen. MzKlMu

[MzKlMu]

Hallo,
ich habe die beiden Links gelöscht. Da kommen Warnungen für Malware und Viren.
Verwende Dropbox.com, da komm so etwas nicht vor.

Und nebenbei, Beispieldb sollte nur das enthalten, das zum Nachstellen des Problems notwendig ist. Und dann noch "Komprimieren/Reparieren" (Access Dienstprogramm) und anschließend Zippen. Dann sollte die Größe auch für das Forum klein genug sein.

[dschroeder1989]

Komprimiert und repariert sowie zippen hatte ich probiert... wie auch immer ich habe jetzt wie empfohlen alle nicht zwingenden Objekte gelöscht.
Ich hoffe jetzt passt alles.

[Beaker s.a.]

Hallo David,
Hat ein bisschen gedauert.
Überarbeitete Version deiner DB anbei.
Was ich gemacht habe:
Den Beziehungen referentielle Integrität verpasst.
Das Feld Fahrtkosten aus Auftritte_Teilnehmer entfernt, da es aktuell
berechnet werden kann. Dafür in die Tabelle Auftritte ein Fremdschlüssel-
Feld auf die Tabelle Kilometer eingefügt.
Auf Basis der Tabelle Kilometer im Formular Auftritte ein Kombifeld
erstellt, das an das neue FK-Feld gebunden ist. Dieses ist dann auch gleich
auf das Auftrittsdatum gefiltert (sobald eins erfasst wurde. Evtl. muss da noch
ein Requery auf das Kombi beim Datumsfeld_AfterUpdate ausgeführt
werden.)
Das Ufo ist jetzt an eine neue Abfrage qTeilnehmer gebunden, in der dann
automatisch die Fahrtkosten aller erfassten Teilnehmer berechnet/angezeigt
werden.

Noch ein Hinweis zu einer Nebenbaustelle, die mir aufgefallen ist. Du hast
jeweils eine Tabelle für Einnahmen und Ausgaben. Dazu reicht eine Tabelle
bzw. ist eine Tabelle sogar besser (für Saldo- u.ä. Berechnungen.)
Einnahme und Ausgabe werden dabei, entweder direkt als + bzw. - Beträge
eingegeben, oder über einen Faktor (+1/-1) unterschieden.

gruss ekkehard

[dschroeder1989]

Vielen Dank erst einmal,
ich versuche jetzt mal in Ruhe alles Nachzuvollziehen.

Sowohl die Einzelgagen als auch die Fahrtkosten hatte ich geplant zu speichern, auch wenn es tendenziell redundant ist. War eine Absprache mit den Vorstandsleuten, die genaue Begründung weiß ich nicht mehr.  Ein Punkt war, dass sich z.B. der Algorithmus für die Gagenverteilung verändern kann und dann Probleme auftreten wenn es nicht berechnet und gespeichert werden würde. Ähnliches galt für die Fahrtkosten wenn es nicht mehr beim Multiplizieren mit einem Betrag bleibt. Dass der Km-Betrag anpassbar ist war zumindest eine "Problem von vornherein ausschließen" Strategie von mir. Käme nur eine Änderung des KM-Betrages in Frage wäre es an der Stelle natürlich redundant. Wenn ich es richtig Überblicke kann ich deinen Lösungspfad aber trotzdem verwenden. Versuch macht klug an der Stelle.

Bezüglich der ref Integritäten: Aktuell hattest du nur die Aktualisierungweitergabe angeklickt... was passiert wenn ich jetzt einen Datensatz aus der Tbl Auftritte lösche? Bleiben die verbundenen Datensätze in Tbl Auftritt_Teilnehmer dann erhalten und verursacht das Probleme? Bzw. müsste ich dann nicht einfach auch die Löschweitergabe anklicken?

Bezüglich der Nebenbaustelle, ist bereits alles gelöst. Es gibt von vornherein verschiedene
Einnahme und Ausgabe-quellen wie zB. Kreditraten und Auftrittsgagen die für die Kassenbuch Ansicht schon per UNION gebündelt werden, da fand ich es nur stringent dann auch die weiteren Einnahmen und Ausgaben zu trennen. Ist vermutlich Geschmackssache. Im geforderten Kassenbuch-Layout sollten Einnahmen und Ausgabe in zwei Spalten aufgeführt sein und dann im Bericht ein Monatssaldo "unter den Stricht" erhalten. Wie auch immer die Baustelle ist für mich geklärt.

Viele Grüße
David

[Beaker s.a.]

Hallo David,
Zum Speichern von Gagen und Fahrtkosten:
Da würde ich die Gagen sogar auch noch in eine eigene Tabelle verschieben,
und die mit der Tabelle Auftritt_Teilnehmer verknüpfen.
Diese ändern sich ja nicht nachträglich, so dass bei einer Änderung der
Berechnung(sformel) nur ein neuer DS angelegt wird. Berechnungsparameter
lassen sich ja neben einem Gültigkeitszeitraum auch in der/den Tabellen
festhalten; - denke ich.
Das Macro zu Gagenberechnung hattest du vor dem Hochladen entfernt, so
dass ich dazu nichts weiter sagen kann.

Zur RI:
Da DS normal nicht gelöscht, sondern eher als inaktiv/abgelaufen o.s.w.
markiert werden, setze ich die Löschweitergabe nur sehr sparsam ein, meist nur
während der Entwicklung, und in fremden DB setze ich sie gar nicht. Da musst
du dir überlegen, wie du das handhaben möchtest.

Bezügl. Nebenbaustelle ist es natürlich deine Entscheidung wie du das einrichtest.

gruss ekkehard

[dschroeder1989]

Guten Abend,
ich habe soeben eine sehr simple Lösung gefunden.
Über eine Abfrage wir der korrekte KM-Satz jeder Auftritte_ID zugeordnet. Und damit kann dann gerechnet werden.

SELECT A.Auftritt_Kerndaten_ID, MAX( KM.Kilometer_Betrag) AS KM_Betrag_Akt
FROM Kilometergeld AS KM, Auftritte_Ber AS A, Auftritt_Teilnehmer
WHERE (((A.Auftritt_Dat) Between [KM].[Dat_von] And [KM].[Dat_bis]))
GROUP BY A.Auftritt_Kerndaten_ID;

Vielen Dank für die vielen Denkanstöße
David