Abfrage mit Blick in den Vortag

Computer: Software & Programmierung Microsoft Access
#1

Hallo Wissende,

ich führe (bisher in Excel) eine recht umfangreiche Statistik. Dort werkelt auch ein VB-Makro, das die Daten nach verschiedenen Sichten anordnet. Nun fliegt mir langsam der Umfang um die Ohren und ich möchte das gern in Access portieren. Hintergedanke ist auch, dass die Daten nur in einer Tabelle liegen und die verschiedenen Sichten über Abfragen keine weiteren Ressourcen verbrauchen.

Ich beschäftige mich grad verstärkt mit SQL und versuche erstmal, vom prozeduralen Denken eines Visual Basic in die „Datensatz-Denke“ von SQL reinzukommen.

Ich brauche euch mal für ein konkretes Problem, folgendes Beispiel:

tbl\_Erfassung

Datum Eingang Bestand
28.09.12 NUL 50
01.10.12 20 60
02.10.12 40 65
04.10.12 10 30

Es wird immer nur erfasst, wieviel Aufträge an einem Tag eingegangen sind (Eingang) und wieviele abends noch liegen (Bestand).

Nun ist es Aufgabe, auszurechnen, wieviel an den entsprechenden Tagen bearbeitet wurde. Am 1.10. sind es in diesem Beispiel 10 Stück (50 vom Vortag + 20 Eingang - 60 Rest). Eine Berechnung für den 28.9. ist nicht möglich und nicht erforderlich, das Datum steht nur für den „Anfangsbestand“.

Eine Abfrage soll mir also für alle Daten (in echt sind das noch ein paar mehr…) die Bearbeitungsmengen liefern. Natürlich sind die Tagesdaten wegen Feiertagen, Wochenend und Sonnenschein nicht immer um Eins aufsteigend.

Mit meinen SQL-Studien wäre ich mittlerweile in der Lage, mit WHERE bzw. mit LIMIT einen einzelnen Datensatz zu lokalisieren und die Berechnung dann für einen Tag durchzuführen. Aber wie kann ich die Abfrage gestalten, wenn ich alle Tage in einem Schlag berechnen will?

Vielen Dank im voraus

Hans-Jürgen

#2

Hallo,

etwa so:

Select tbl_Erfassung.*, (Select top 1 temp.bestand from tbl_Erfassung as temp where temp.datum

#3

Dank und Nachfrage
Hi,

SUPER, vielen Dank, es klappt.

Ich habe vor, jedem Erfasser der Daten eine separate Erfassungsdatei zu machen, die dann auch über den Server abends gesichert wird. Ich habe dann noch für mich und das Management eine Auswertungsdatei, wo die genannte Berechnung durchgeführt wird. Ich habe vor, die Erfassungstabellen über die Dateiverknüpfung mir in die Auswertungsdatei „hineinzuspiegeln“.

Vielen Dank auch für den Aufbautipp. Es geht nicht um Eingang von Waren, sondern von Aufträgen. In jeder Reporting-Einheit gibt es einen, der manuell zählt, wieviel Aufträge eingegangen und wieviel liegengeblieben sind. Daraus wird dann die Bearbeitungsmenge errechnet. Das ist sinnvoll so, weil man ansonsten die bearbeiteten Stücke bei allen Bearbeitern zählen müsste, ist fehleranfälliger.

Apropos Fehler: Gibt es hier auch die Möglichkeit der Plausibilitätskontrolle bereits bei der Erfassung ? Die Rechnung lautet ja:

Bestand Vortag + Eingang - Bestand heute = Bearbeitungsmenge.

Aus logischen Gründen darf die Bearbeitungsmenge nicht negativ sein. Es muss also gegeben sein

Bestand heute

#4

Hallo,

ich befürchte, dass das Konzept der DB etwas sehr strapaziert wird…

Ob Aufträge oder Senftuben behandelt werden, ist völlig egal. Die „Zählerei“ ist auch eher fragwürdig. Hier sollte es eine Tabelle „tblAufträge“ geben, die für jeden Auftrag einen Datensatz bereitstellt. Mit einer weiteren Tabelle „tblAuftragsstatus“ in 1:n-Beziehung wird der an einem bestimmten Datum gültige Zustand festgehalten. DAmit ist dann ordentlich eine Überwachung und Auswertung der Geschichte mögich.

Die Pflege der einzelnen Aufträge übernimmt jede Abteilung für sich selber (nix mit „zählen“…) Jeder User (Abteilung) hat sein eigenes Frontend, das mit einem zentralen Backend auf einem Server (Access-DB oder SQL-Server) zusammenspielt.

Eine Plausibilitätprüfung mit Aktion dahinter ist in Tabellen /Abfragen nicht möglich. Gleichwohl kann man eine „Überprüfungsrechnung“ hernehmen und als Ergebnis True oder False in der jeweiligen Datensatz-Zeile anzeigen. Die Abfragen sind lediglich Auswahlabfragen, keine Aktionsabfragen.

Zu vermeiden ist auf jeden Fall, in den Tabellen direkt Datenänderungen vorzunehmen. Das ist den Formularen (in denen dann Plausi-Prüfungen leicht zu realisieren sind= vorbehalten.

Gruß
Franz, DF6GL

#5

Leider noch eine Nachfrage nötig
Hallo,

vielen Dank für deine Mühe mir mir SQL-Anfänger. Habe das Thema Palusibilität verworfen, denn es gibt noch ein anderes Problem.

Ich muss dazu sagen, dass die die Ursprungsfrage vereinfacht gestellt habe. Es gibt nicht nur eine Auftragsart, sondern zehn. Jeder Standort hat also eine Tabelle mit 21 Spalten: DDAT für das Datum (Primärschlüssel), 10 Spalten für Eingangszahlen (E…) und 10 für Rückstand (R…). Ich reduziere das hier mal beisipelhaft auf nur drei Auftragsarten, die ich REK, ZAH und SON nenne.

DDAT EREK EZAH ESON RREK RZAH RSON
28.09.12 NUK NUL NUL 20 30 40
01.10.12 40 40 50 30 30 50

Entsprechend deines Tipps sieht die Abfrage so aus:
SELECT
DDAT,
(SELECT TOP 1 Vortag.RREK FROM Ost AS Vortag WHERE Vortag.DDAT

#6

Hallo,

vermutlich meint er sowas:

SELECT
DDAT,
(SELECT TOP 1 Vortag.RREK + Ost.EREK - Ost.RREK AS BREK ,Vortag.RZAH + Ost.EZAH - Ost.RZAH AS BZAH, Vortag.RSON + Ost.ESON - Ost.RSON AS BSON
FROM Ost AS Vortag WHERE Vortag.DDAT

#7

Fehlermeldung
Hallo,

vielen Dank. Ich habe das mal ausprobiert und bekomme die Fehlermeldung: „Sie haben eine Unterabfrage erstellt, die mehrere Felder zurückgeben kann, ohne im FROM-Abschnitt der Hauptabfrage das reservierte Wort EXISTS zu verwenden. Überarbeiten Sie die SELCECT-Anweisung der Unterabfrage so, dass nur ein Feld abgerufen wird.“

Häh ?

Kannst du bitte bitte noch einmal draufschauen ? Vielen Dank.

Hans-Jürgen

#8

Hallo,

naja, mit der Unterabfrage klappt das nicht so…Felder aus der UA-Selectliste können nicht in die Selectliste der HA transportiert werden.

Ich kann Dir nur sowas anbieten:

SELECT DDAT,
Dmax(„RREK“, „Ost“, "DDAT

1 Like