Hallo, ich hänge momentan am Verständnis zu einer Unterabfrage die Datensätze nummeriert (funktioniert einwandfrei).
Es gibt eine einfache Tabelle die Tastenkürzel enthält (sh. Anhang "Tabelle").
Über eine Unterabfrage wird im Zielfeld ("Nr") einer Abfrage eine Nummerierung generiert:
Nr: (SELECT Count(*) FROM tblTastenkuerzel AS tblTK WHERE tblTK.Taste < tblTastenkuerzel.Taste )+1
Ich hänge hier bei folgendem Ausdruck in dieser Anweisung:
tblTK.Taste < tblTastenkuerzel
Hier wird doch ein temporäres Textfeld (Aliastabelle tblTK mit Textfeld Taste) mit dem gleichen Textfeld der Originaltabelle tblTastenkuerzel verglichen (Abfrage kleiner als). Und hier fehlt mir irgendwie der Durchblick wie das gehen soll: Textfelder vergleichen mit "<"?????.
Alle anderen Angaben sind soweit klar. Im Anhang auch nochmal das Ergebnis der Abfrage. Könnte mir jemand helfen da etwas mehr durchzublicken?
Das Ganze gibt es übrigens auch noch mal über eine Domänenfuntkion.
Grüße
Herbert
PS:
Das Beispiel entstammt übrigens dem Buch Access 2013 von Lorenz Hölscher
Hallo,
diese Unterabfrage darfst Du nicht isoliert sehen....
(SELECT Count(*) FROM tblTastenkuerzel AS tblTK WHERE tblTK.Taste < tblTastenkuerzel.Taste )+1
zählt die Datensätze aus Tabelle "tblTK" (Alias für tblTastenkuerzel) mit der Bedingung, dass der "Taste"-Wert kleiner ist als der aktuelle Taste-Wert der übergeordneten Tabelle "tblTastenkuerzel". Hierfür ist eine aufsteigende Sortierung des "Taste"-Feldes (Spalte) erforderlich.
Select
(SELECT Count(*) FROM tblTastenkuerzel AS tblTK WHERE tblTK.Taste < tblTastenkuerzel.Taste )+1 As Nr
Taste,
Beschreibung
From tblTastenkuerzel Order by tblTastenkuerzel.Taste
oder anders beschrieben:
wenn die Hauptabfrage den 3. Datensatz bearbeitet (den "Taste"-Wert für den 3. DS liefert), liefert die Unterabfrage die Anzahl der DS (erhöht um 1 in der berechneten Spalte "Nr") , die einen kleineren "Taste"-Wert als den der Hauptabfrage enthalten.
Hallo Franz,
vielen Dank, das muss ich erst mal genau überdenken!
Du hast geschrieben:
ZitatHierfür ist eine aufsteigende Sortierung des "Taste"-Feldes (Spalte) erforderlich.
Merkwürdigerweise funktioniert das Ganze mit und ohne aufsteigende Sortierung - seltsam!
Gruß
Herbert
Die Sortierung ist an der Stelle selbstredend nicht nötig. Es wird in der korrelierenden Unterabfrage alles gezählt, was kleiner als hier der Wert für Taste in der Hauptabfrage ist.
Siehe auch Grundlagen - SQL ist leicht (11) - Reihenfolge der Abfrageabarbeitung (https://www.ms-office-forum.net/forum/showthread.php?p=1883328#post1883328): Sortieren erfolgt recht spät, zu spät fürs Zählen (Aggregieren).
Hallo Eberhard,
vielen Dank für deine Antwort! Wieder etwas gelernt! Versuche mich mal näher in das Thema einzuarbeiten und habe ein bisschen mit der "berühmten" Northwind" Datenbank online Versuche gestartet. Und hier komme ich leider auch an eine Stelle, wo ich nicht weiterkomme.
Hier meine selbstgebastelte SQL Anweisung die bei GROUP BY einen Fehler verursacht:
SELECT o.OrderID AS OID, o.OrderDate AS OD, c.CustomerName AS CN, d.ProductID AS ART, d.Quantity AS QUA
FROM Customers AS c, Orders AS o, OrderDetails AS d
WHERE c.CustomerName="Ernst Handel" AND c.CustomerID=o.CustomerID;
GROUP BY
o.OrderDate
ORDER BY
o.OrderDate
So wie du das in deinem Beispiel "SQL ist leicht" vorgestellt hast müsste das doch funktionieren??
Grüße
Herbert
Hallo,
das Semikolon vor "Group" ist zu eliminieren. Und auch hier ist das Order by überflüssig.
Des Weiteren solltest Du eine über die drei Tabellen verknüpfende Abfrage erzeugen .... (inner Join ...... on ....)
Super vielen Dank! Hat so geklappt und auch richtige Ergebnisse erzeugt mit dieser Anweisung:
SELECT o.OrderID AS OID, o.OrderDate AS OD, c.CustomerName AS CN, d.ProductID AS ART, d.Quantity AS QUA
FROM Customers AS c INNER JOIN Orders AS o ON (c.CustomerID = o.CustomerID), Orders INNER JOIN OrderDetails AS d ON (o.OrderID = d.OrderID)
WHERE c.CustomerName="Ernst Handel" AND c.CustomerID=o.CustomerID
GROUP BY
o.OrderDate
Nun noch eine Frage zu Aggregatfunktionen: Ich habe gesehen, dass diese immer direkt nach der SELECT Anweisung erscheinen also z.B.:
SELECT .....
Sum(....) AS ....
Bei Eberhards Link "SQL ist leicht" wird bei Punkt 3 etwas über das aggregieren aufgeführt.
Da die SELECT Anweisung ganz am Ende durchgeführt wird: Werden die Aggregatfunktionen
danach erst ausgeführt?? D.h. stehen diese immer nach der SELECT Anweisung???
Gruß
Herbert
Hallo,
ZitatDa die SELECT Anweisung ganz am Ende durchgeführt wird
Was meinst Du damit?
Die Select-Liste ( Felder zwischen "Select" und "From" ) definiert nur die Spalten, die entweder aus der Tabelle stammen oder eigenständig berechnet werden.
Die Reihenfolge der Felder (Spalten) schlägt sich in der Abfrage-Ansicht (von links nach rechts) nieder.
Wenn z. B. die Summe (Summierung) über eine Spalte an 3. Stelle in der Abfrageansicht stehen soll, dann kommt die Sum(Feldname)-Funktion an 3. Stelle in der Select-Liste zu stehen.
Eine berechnete Spalte kann nicht nur aus einer Funktion (Sum, Max, etc.) ioder einem mathmatischen Ausdruck bestehen, es kann sich auch um eine Unterabfrage handeln (siehe die "Durchnummerierung")
Der SELECT-Teil organisiert die Ausgabe nach außen, also die Felder, die man dann als Ergebnis sieht. Das alleine sollte verdeutlichen, dass dort relativ spät etwas zu tun ist.
Aggregierungen werden aber schon vorher ausgeführt, nämlich im zusammenhang mit Gruppierungen. Im HAVING-Teil kann man auch nach Aggregaten filtern, das hast Du doch auch gelesen.
Hallo Franz,
vielen Dank! Ich wollte eigentlich nur wissen, ob im Ablauf der Abfrage die Aggregatfunktion am Ende kommt. Da die SELECT-Anweisung ja am Ende ausgeführt wird ist das eigentlich klar.
sh. "SQL ist leicht" von Eberhard:
Zitat6. Schritt: SELECT-Teil (Rename, Neunamensgebung)
Jetzt wird die Ausgabe des Abfrageergebnisses vorbereitet. Im Besonderen werden die angewiesenen Spaltenaliase, die in Folge als Feldnamen nach außen wirken, gesetzt.
Hier übrigens der komplette SQL-Code zur Durchnummerierung mit Haupt- und Unterabfrage:
SELECT (SELECT Count(*) FROM tblTastenkuerzel AS tblTK WHERE tblTK.Taste < tblTastenkuerzel.Taste )+1 AS Nr, tblTastenkuerzel.Taste, tblTastenkuerzel.Beschreibung
FROM tblTastenkuerzel
ORDER BY tblTastenkuerzel.Taste;
Lässt man '+1' weg, fängt er bei "0" an zu zählen: 0,1,2
Ersetzt man "<" durch ">" erfolgt eine umgekehrte Sortierung: 3,2,1
Ersetzt man "<" durch "<=" fängt er bei "2" an zu zählen: 2,3,4
Vielen Dank für eure Hilfe!
Gruß
Herbert
Hallo Eberhard,
Danke für die Erklärungen!
Meintest du im Punkt 3. folgendes:
WHERE filtert vor der Gruppierung und HAVING danach?
Wobei man bei HAVING auch Aggregatfunktionen filtern kann:
HAVING
COUNT(X.FeldC) > 3
ORDER BY
X.FeldA
Nur filtern oder auch direkt Berechnungen durchführen z.B. Summenberechnungen etc.?
Gruß
Herbert
ZitatWobei man bei HAVING auch Aggregatfunktionen filtern kann
Falsche Formulierung. Filtern kann man an der Stelle die Ergebnisse der Aggregierung, und dazu muss diese ja wohl schon ausgeführt worden sein.
Im HAVING-Teil wird man dann nicht "auch" Aggregate filtern, sondern
nur Aggregate. Alles andere macht keinen Sinn in aufwandstechnischer Betrachtung, auch wenn der Abfrageeditor mit seinen Ergebnissen zu diesem Irrglauben beiträgt => ist der Chef (Entwickler) gescheiter als der Assi oder übernimmt er alles kritiklos?
Ansonsten:
Was man kann, kannst Du an Hand Deiner Vorstellungen selber ausprobieren. Es gibt recht oft verschiedene Formulierungen für SQL-Anweisungen, um zu einem gleichen Ergebnis zu kommen. Das kommt wie im verlinkten Beitrag beschrieben daher, dass SQL nur beschreibt, was zu machen ist.
Hallo Franz, hallo Eberhard,
vielen Dank für eure Hilfe! Ich habe SQL bisher etwas vernachlässigt, da man ja sehr viel in Access über Kriterien und Gruppierungen in der Abfrage machen kann, ohne sich über SQL Gedanken machen zu müssen. Aber bei speziellen Dingen wie z.B. Unterabfragen geht das nur schwer ohne SQL Kenntnisse.
Nochmals Danke!
Gruß Herbert