Access, subtrahieren zweier Datensätze
Tabelle Umsatz mit einer Spalte Wert
Hey Leute,
in Excel ist so etwas ganz einfach zu lösen, da rechne ich einfach z.B. A3-A2 und ziehe dies einfach runter, so dass dann A4-A3 usw. kommt.
Wie kann ich das in Access bewältigen?? SQL??
Danke
Hey Leute,
in Excel ist so etwas ganz einfach zu lösen, da rechne ich einfach z.B. A3-A2 und ziehe dies einfach runter, so dass dann A4-A3 usw. kommt.
Wie kann ich das in Access bewältigen?? SQL??
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 160679
Url: https://administrator.de/contentid/160679
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
20 Kommentare
Neuester Kommentar
Moin Moin,
so schwer es fällt, vergiss Excel.
Tabellen sind in Access ausschließlich dafür da, Daten zu speichern.
Auswertungen, Bearbeiten und Anzeigen werden über Formulare und Berichte gemacht.
Berechnungen kann man sowohl in Formularen und Berichten durchführen, als auch Abfragen (SQL) dafür nutzen.
Die Frage ist also: was willst du als Ergebnis erreichen?
Grüße aus Rostock
Wolfgang
(Netwolf)
so schwer es fällt, vergiss Excel.
Tabellen sind in Access ausschließlich dafür da, Daten zu speichern.
Auswertungen, Bearbeiten und Anzeigen werden über Formulare und Berichte gemacht.
Berechnungen kann man sowohl in Formularen und Berichten durchführen, als auch Abfragen (SQL) dafür nutzen.
Die Frage ist also: was willst du als Ergebnis erreichen?
Grüße aus Rostock
Wolfgang
(Netwolf)
Moin etnobommel1989,
ich bin nicht sicher, ob es sich wirklich noch lohnt, solche Kunststückchen für "Wetten dass.." einzuüben -
angeblich will sich der Thomas "ForEverYoung" Gottschalk doch ganzjährig zum Winterschlaf in seine Schweineschwarten-Goldbärenhöhle zurückziehen.
Ich hatte dir doch neulich in einem ähnlichen Beitrag geschrieben, dass die physikalische Reihenfolge von Datensätzen in einer Datenbanktabelle vollkommen willkürlich und zufällig ist.
Eine Abfrage "SELECT wert FROM Umsatz" allerdings ist nicht nur unter Datenbankgesichtspunkten albern.
Ein "Umsatz" hängt doch nicht frei schwebend im Raum, sondern beschreibt doch so etwas wie "Preis*Stückzahl" bezogen auf einen oder mehrere Artikel.
Und vor allem auf einen Zeitraum (Tag oder Monat oder Quartal) bezogen.
Du kannst doch unmöglich nur Tabellen haben, die aus einer Autowert-Spalte und einem Nutzfeld bestehen.
Und doch nicht nur Fragestellungen, die sich auf Vorgänger-Nachfolger-beziehungen beziehen.
Dafür ist doch eine Datenbank nur geeignet, wenn du auch Vorgänger und Nachfolger/Parent und Child logisch verkettest.
Einfach nur alle Daten in eine lange lange Reihe kippen und dann Umsatzdifferenzen bilden - das mag ein Plan sein, aber er könnte noch verfeinert werden.
Wie sieht den jetzt die "Umsatz"-Tabelle wirklich aus - vor allem, was ist der identifizierende Schlüssel und/oder die Sortierreihenfolge?
Grüße
Biber
ich bin nicht sicher, ob es sich wirklich noch lohnt, solche Kunststückchen für "Wetten dass.." einzuüben -
angeblich will sich der Thomas "ForEverYoung" Gottschalk doch ganzjährig zum Winterschlaf in seine Schweineschwarten-Goldbärenhöhle zurückziehen.
Ich hatte dir doch neulich in einem ähnlichen Beitrag geschrieben, dass die physikalische Reihenfolge von Datensätzen in einer Datenbanktabelle vollkommen willkürlich und zufällig ist.
Eine Abfrage "SELECT wert FROM Umsatz" allerdings ist nicht nur unter Datenbankgesichtspunkten albern.
Ein "Umsatz" hängt doch nicht frei schwebend im Raum, sondern beschreibt doch so etwas wie "Preis*Stückzahl" bezogen auf einen oder mehrere Artikel.
Und vor allem auf einen Zeitraum (Tag oder Monat oder Quartal) bezogen.
Du kannst doch unmöglich nur Tabellen haben, die aus einer Autowert-Spalte und einem Nutzfeld bestehen.
Und doch nicht nur Fragestellungen, die sich auf Vorgänger-Nachfolger-beziehungen beziehen.
Dafür ist doch eine Datenbank nur geeignet, wenn du auch Vorgänger und Nachfolger/Parent und Child logisch verkettest.
Einfach nur alle Daten in eine lange lange Reihe kippen und dann Umsatzdifferenzen bilden - das mag ein Plan sein, aber er könnte noch verfeinert werden.
Wie sieht den jetzt die "Umsatz"-Tabelle wirklich aus - vor allem, was ist der identifizierende Schlüssel und/oder die Sortierreihenfolge?
Grüße
Biber
Moin etnobommel1989,
nochmal...
Es gibt in Datentabellen keinen "ersten" und keinen "zweiten" Datensatz.
Du bist gedanklich noch in Excel... da kannst du automatisch eine Zeile eingeben und der Cursor springt in die nächste Zeile.
Und ganz links steht dort eine Zeilennummer 1, 2, 3, ...viele.
Jetzt sind wir bei Datenbanktabellen. Da kannst du nicht sagen "Ziehe Wert von Satz 16 vom Wert von Satz 15 ab".
Wenn du die Struktur deiner "umsatz"-Tabelle nicht preisgeben kannst wegen dieser ganzen Designpiraten, die das abkupfern, dann gib uns eine Tablle "Fritz" oder "Heinz". Aber bitte mit der Info (wie oben schon gebettelt)
Grüße
Biber
nochmal...
zudem ginge dies beim ersten Datensatz ja nicht weil davor noch kein Datensatz vorhanden ist,
also müsste er beim zweiten Datensaetz anfangen und den ersten Datensatz subtrahieren
also müsste er beim zweiten Datensaetz anfangen und den ersten Datensatz subtrahieren
Es gibt in Datentabellen keinen "ersten" und keinen "zweiten" Datensatz.
Du bist gedanklich noch in Excel... da kannst du automatisch eine Zeile eingeben und der Cursor springt in die nächste Zeile.
Und ganz links steht dort eine Zeilennummer 1, 2, 3, ...viele.
Jetzt sind wir bei Datenbanktabellen. Da kannst du nicht sagen "Ziehe Wert von Satz 16 vom Wert von Satz 15 ab".
Wenn du die Struktur deiner "umsatz"-Tabelle nicht preisgeben kannst wegen dieser ganzen Designpiraten, die das abkupfern, dann gib uns eine Tablle "Fritz" oder "Heinz". Aber bitte mit der Info (wie oben schon gebettelt)
...was ist der identifizierende Schlüssel und/oder die Sortierreihenfolge?
Grüße
Biber
Moin etnobommel1989,
wenn dieses Access meint, statt "...FROM dutzend a" besser "...FROM dutzend AS a" schreiben zu müssen...
Derlei konstruktive Verbesserungen habe ich schon damals bei meiner Ex-Schwiegermutti geliebt.
Und ja, natürlich darfst du auch auf eine Abfrage statt auf eine Tabelle zugreifen und nochmals ja, du darfst deine Abfragen auch "Dutzend" nennen,
wenn das dem Dokumentationsanspruch deines Cheffes genügt.
Also - statt Tabelle "Umsatz" mit Spalte "Wert" haben wir jetzt eine Abfrage "Dutzend" mit zwei Spalten "Runde" und "Dutzend" ..
Noch irgendwelche Details, die relevant sein könnten?
Grüße
Biber
wenn dieses Access meint, statt "...FROM dutzend a" besser "...FROM dutzend AS a" schreiben zu müssen...
Derlei konstruktive Verbesserungen habe ich schon damals bei meiner Ex-Schwiegermutti geliebt.
Und ja, natürlich darfst du auch auf eine Abfrage statt auf eine Tabelle zugreifen und nochmals ja, du darfst deine Abfragen auch "Dutzend" nennen,
wenn das dem Dokumentationsanspruch deines Cheffes genügt.
Also - statt Tabelle "Umsatz" mit Spalte "Wert" haben wir jetzt eine Abfrage "Dutzend" mit zwei Spalten "Runde" und "Dutzend" ..
Noch irgendwelche Details, die relevant sein könnten?
Grüße
Biber
Hallo,
nur so als kleine Randanmerkung. Microsoft nutzt an einer Stelle fast genau die gleich Berechnung.
http://de.wikipedia.org/wiki/Microsoft_Dynamics_NAV
im Punkt: SIFT Technologie
nur so als kleine Randanmerkung. Microsoft nutzt an einer Stelle fast genau die gleich Berechnung.
http://de.wikipedia.org/wiki/Microsoft_Dynamics_NAV
im Punkt: SIFT Technologie
Moin wiesi200,
weitere Parallele: die Redmonder Nachwuchstalente halten ebenfalls einen INNER JOIN auf sich selbst für übertrieben.
@etnobommel1989
Stimmt es denn, dass sich die SQL-Formulierung
Egal, Haken is' dran...
Grüße
Biber
weitere Parallele: die Redmonder Nachwuchstalente halten ebenfalls einen INNER JOIN auf sich selbst für übertrieben.
@etnobommel1989
Stimmt es denn, dass sich die SQL-Formulierung
SELECT ... ...FROM Dutzend_1 INNER JOIN Dutzend_1 AS a ON [Dutzend_1].[Runde]=a.Runde
.. übersetzen liesse mit "Hole mir ... aus Tabelle Dutzend_1, aber nur die Sätze, die auch in dieser Tabelle vorhanden sind"?Egal, Haken is' dran...
Grüße
Biber
Wieso erkennt access das nicht?
Wenn ich auf einen oder beide Aliasnamen verzichten würde, dann wären öfters mal einzelne Spalten (insbesondere "Differenz") leer.
Weil Access dann z.b. das Feld "Runde" aus der falschen (logischen) Tabelle holt.
Die einzige Schreibweise, mit der ich unterstellen kann, dass
a) ich weiss, welche Felder ich miteinander vergleichen will und
b) auch Access weiss, welche Felder ich meine
..ist doch JEDES irgendwo angegebene Anzeige- oder Vergleichsfeld mit einem Alias anzusprechen.
Unmissverständlich auch für den Access-Parser/die Access-Parserin:
vollkommen gleichbedeutend mit
Und minimal (aber eben möglicherweise missverständlich) wäre für eine der beiden logischen Tabellen "Dutzend_1" ein Alias erforderlich.
Was macht denn eigentlich der Parallelthread mit dem Münzen-aufn-Kopp-hau-Problem? Auch erledigt?
Grüße
Biber
Wenn ich auf einen oder beide Aliasnamen verzichten würde, dann wären öfters mal einzelne Spalten (insbesondere "Differenz") leer.
Weil Access dann z.b. das Feld "Runde" aus der falschen (logischen) Tabelle holt.
Die einzige Schreibweise, mit der ich unterstellen kann, dass
a) ich weiss, welche Felder ich miteinander vergleichen will und
b) auch Access weiss, welche Felder ich meine
..ist doch JEDES irgendwo angegebene Anzeige- oder Vergleichsfeld mit einem Alias anzusprechen.
Unmissverständlich auch für den Access-Parser/die Access-Parserin:
SELECT a.Runde, a.Dutzend, a.Runde-(select max(x.Runde) from dutzend_1 x where x.Runde < a.runde) AS Differenz
FROM dutzend_1 a;
SELECT a.Runde, a.Dutzend, a.Runde-(select max(x.Runde) from dutzend_1 AS x where x.Runde < a.runde) AS Differenz
FROM dutzend_1 AS a;
Und minimal (aber eben möglicherweise missverständlich) wäre für eine der beiden logischen Tabellen "Dutzend_1" ein Alias erforderlich.
Was macht denn eigentlich der Parallelthread mit dem Münzen-aufn-Kopp-hau-Problem? Auch erledigt?
Grüße
Biber
Hallo,
ich würde es mit VBA machen.
Beispl. Tab oder Abfrage zum selectieren.
Tabelle Test -> Felder Wert + ergeb
ohne SQL und mit jeder möglichen aritmetik.
Beispiel code:
Sub add_altwert()
Dim Altwert As Long
Dim db As Database, wertTab As Recordset
Set db = CurrentDb
Set wertTab = db.OpenRecordset("Test", dbOpenDynaset)
With wertTab
.MoveFirst
Altwert = ![wert]
.MoveNext
Do Until .EOF
.Edit
![ergeb] = ![wert] + Altwert
.Update
Altwert = ![wert]
.MoveNext
Loop
.Close
End With
End Sub
ich würde es mit VBA machen.
Beispl. Tab oder Abfrage zum selectieren.
Tabelle Test -> Felder Wert + ergeb
ohne SQL und mit jeder möglichen aritmetik.
Beispiel code:
Sub add_altwert()
Dim Altwert As Long
Dim db As Database, wertTab As Recordset
Set db = CurrentDb
Set wertTab = db.OpenRecordset("Test", dbOpenDynaset)
With wertTab
.MoveFirst
Altwert = ![wert]
.MoveNext
Do Until .EOF
.Edit
![ergeb] = ![wert] + Altwert
.Update
Altwert = ![wert]
.MoveNext
Loop
.Close
End With
End Sub
Hallo Biber,
ich bin ein Neuling und habe das gleiche Problem. Nachdem ich nun Stunden versucht habe, den o.g. Code umzusetzen komme ich nicht weiter.
Wäre es möglich, mir die o.g. SQL-Anweisung für meine Anforderung umzuschreiben ?
Meine Parameter:
Tabelle: Tourenzettel
Abfrage: KM_PRUEFUNG
1. Spalte = KM_ANFANG
2. Spalte = KM_ENDE
3. Spalte = Differenz KM_ENDE - KM_ANFANG
Ergebnis soll sein, über eine Abfrage KM_Ende (1. Satz) mit KM_Anfang (2.Satz) zu vergleichen .. es sollte NULL sein. Etwaige Abweichung sollten somit erkennbar sein.
Das würde mir wirklich helfen. Vielen Dank im Voraus und Grüße aus Wilhelmshaven
Andreas
ich bin ein Neuling und habe das gleiche Problem. Nachdem ich nun Stunden versucht habe, den o.g. Code umzusetzen komme ich nicht weiter.
Wäre es möglich, mir die o.g. SQL-Anweisung für meine Anforderung umzuschreiben ?
Meine Parameter:
Tabelle: Tourenzettel
Abfrage: KM_PRUEFUNG
1. Spalte = KM_ANFANG
2. Spalte = KM_ENDE
3. Spalte = Differenz KM_ENDE - KM_ANFANG
Ergebnis soll sein, über eine Abfrage KM_Ende (1. Satz) mit KM_Anfang (2.Satz) zu vergleichen .. es sollte NULL sein. Etwaige Abweichung sollten somit erkennbar sein.
Das würde mir wirklich helfen. Vielen Dank im Voraus und Grüße aus Wilhelmshaven
Andreas