Materialbestand berechnen

[jobo]

Zitat von Luckner:

.. weitergebracht. Jetzt werde ich mich mit den Join's beschäftigen, weil so richtig habe ich die Funktionsweise eines Join's nicht verstanden.

JOIN und seine Varianten, z.B. LEFT JOIN ist eine spezifische Form von WHERE. Sie ist standardisiert und funktioniert so für verschiedene DB Hersteller identisch (nicht alle haben den vollen Standard bzw. dessen Besonderheiten umgesetzt, alle haben aber Eigenheiten jenseits des Standards, klar).

JOIN dient explizit der Verknüpfung von 2 Datenquellen, während WHERE das teilweise auch kann, hauptsächlich aber eine Filterfunktion darstellt. (Mit der Filterfunktion wird auch die Tabellenverknüpfung erreicht)

JOIN ist moderner und hat verschiedene Vorteile. Nicht unbedingt offensichtlich für Leute, die es nicht kennen: JOIN erhöht die Lesbarkeit eines Select Statements. Man kann direkt lesen, welche Tabellen verknüpft sind (und wie) und so auch leichter bemerken, wenn eine Verknüpfung fehlt oder falsch ist. Alles was nicht JOIN ist, kommt ins WHERE und filtert "nur noch" das Gesamtergebnis. Das ist bei komplexen Statements naturgemäß besonders hilfreich.

JOIN ist (oft) mächtiger als WHERE, von FULL JOIN, über LEFT, RIGHT bis FULL OUTER kann man schon sehr viel abbilden. Es gibt weitere ..

JOIN hilft der Abfrage Optimierung (je nach Hersteller). Bedeutet nichts anderes, als das damit auch die DB im SQL Statement besser erkennen kann, wie sie am besten an eine Abfrage rangeht.

Nach der Empfehlung von Delphi.Narium würde ich noch ergänzen, dass es beim SQL lernen sehr hilfreich ist, selbst mit einer DB kleine Beispiele auszuprobieren, die auch optisch / im Kopf leicht nachvollziehbar sind. Geht sogar online mit vielen DB.

https://dbfiddle.uk/?rdbms=sqlserver...86707996fcf359

[Luckner]

Hallo Delphi.Narium, hallo jobo,

danke für die Links. Werde mich mit beiden beschäftigt. Den Link von jobo finde ich genial, weil man dort gleich einige selection's ausprobieren kann. Wird mir richtig helfen.

Vielen Dank.

Gruß, Luckner

[Luckner]

Jetzt versuche ich die Materialnummer einer Lieferanten-Nr aus einer 3. Tabelle zu zuordnen. in der Tabelle 'Material-Stamm' gibt es die Felder 'Material-Stamm.Mat-Nr' und
'Material-Stamm.Lieferanten-Nr'. Meine Erweiterung der Select-Anweisung wäre folgende:

Code:

SELECT Materialrollen.Rollennummer, Materialrollen.[Mat-Nr], SUM(Materialrollen.[Arb-Breite]   *  Materialrollen.lfm) as quadratmeter,  [Material-Stamm].[Lieferanten-Nr] 
FROM Materialrollen LEFT JOIN Rollenlager ON (Materialrollen.Rollennummer = Rollenlager.Rollennummer) 
LEFT JOIN [Material-Stamm] ON ([Material-Stamm].[Mat-Nr]  = Materialrollen.[Mat-Nr])
GROUP BY Materialrollen.[Mat-Nr], Materialrollen.Rollennummer

Bekomme jetzt den Fehler: Fehler bei der Authentifizierung.

Habe ich jetzt die eckigen Klammern fasch, oder die 2.-te JOIN-Anweisung ist hier falsch.

Gruß, Luckner

[DeddyH]

Wenn Du Aggregatfunktionen wie SUM benutzt, gehören alle Nicht-Aggregat-Felder der Ergebnismenge ins GROUP BY, also auch [Material-Stamm].[Lieferanten-Nr].

[Luckner]

Sorry, mein Fehler. Habe den Connections String vergessen einzugeben

Mit

Code:

SELECT Materialrollen.Rollennummer, Materialrollen.[Mat-Nr], SUM(Materialrollen.[Arb-Breite]   *  Materialrollen.lfm) as quadratmeter,  [Material-Stamm].[Lieferanten-Nr] 
FROM Materialrollen LEFT JOIN Rollenlager ON (Materialrollen.Rollennummer = Rollenlager.Rollennummer) 
LEFT JOIN [Material-Stamm] ON ([Material-Stamm].[Mat-Nr]  = Materialrollen.[Mat-Nr])
GROUP BY Materialrollen.[Mat-Nr], Materialrollen.Rollennummer, [Material-Stamm].[Lieferanten-Nr]

bekomme ich jetzt einen Syntaxfehler (fehlender Operator zwischen '(Materialrollen.Rollennummer = Rollenlager.Rollennummer)
LEFT JOIN [Material-Stamm] ON ([Material-Stamm].[Mat-Nr] = Materialrollen.[Mat-Nr])'

Luckner

[Delphi.Narium]

Sieht eigentlich richtig aus, aber derda sagt was anderes: Multiple LEFT JOINs in MS Access Database (was mir bisher nicht bekannt war und mir fehlt die Möglichkeit es zu testen).

Wenn ich's halbwegs recht überblicke, könnte dabei sowas rauskommen:

SQL-Code:

SELECT 
  Materialrollen.Rollennummer, 
  Materialrollen.[Mat-Nr], 
  SUM(Materialrollen.[Arb-Breite] * Materialrollen.lfm) as quadratmeter, 
  [Material-Stamm].[Lieferanten-Nr]
FROM 
  (
   Materialrollen 
   LEFT JOIN Rollenlager ON (Materialrollen.Rollennummer = Rollenlager.Rollennummer)
  )
LEFT JOIN [Material-Stamm] ON ([Material-Stamm].[Mat-Nr] = Materialrollen.[Mat-Nr])
GROUP BY 
  Materialrollen.[Mat-Nr], 
  Materialrollen.Rollennummer, 
  [Material-Stamm].[Lieferanten-Nr]

MS-Access <-> SQL-Standard: Zwei fremde Welten treffen aufeinander
Es ist immer wieder für eine Überraschung gut

[jobo]

Alles weglassen, was überflüssig ist und Fehler eingrenzen.
Die Klammern in "join.. on (..) " können sowieso weg. (Außer vielleicht bei Access ..)
Alle Felder in Select Clause raus, ersetzten durch 1 oder so. Passend dazu Group By raus.
usw.
Jeweils ausprobieren, wie sich die Fehlermeldung ändert.

dann:
Die eckigen Klammern sind k... ein Spaß!
Zur Lesbarkeit wenigstens die Tabellennamen mit Alias ersetzen, ab da Aliase verwenden, wo möglich.
Du verwendest "sogar" Mischbetrieb, mit und ohne Klammern. Dabei können doofe Sachen passieren.
Eine Tabelle, die mit Klammerung erzeugt wurde, aber eigentlich, dank brauchbarer Schreibweise auch ohne funktionieren würde, funktioniert in manchen Systemen dann nur in der exakten Klammerschreibweise. Großzügige Handhabung von Groß- und Kleinschreibweise gibt es dann nicht mehr. Folge: Feld/ Tabelle nicht erkannt, Abfrage Parser macht die Grätsche. Passende Fehlermeldung Glückssache. Auch hier gilt: Keine Ahnung, was Access dazu sagt.

Auch wenn es hier zu spät ist. Meine dringende Empfehlung: ANSI Zeichensatz (nur Buchstaben, u.U. Zahlen) ohne Leerzeichen für Datenbankobjekte. Das spart viel Ärger und bringt viel Übersichtlichkeit.

OT:Was ich auch nicht verstehe, ist dann der Kontrast zwischen schicken Umlauten und Sinn entstellenenden Abkürzungen, nur um z.B. 4 Buchstaben zu sparen. Ebenso Fremdsprach Mischmash.