Materialbestand berechnen

[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.

[Luckner]

Hallo jobo,
die Tabellennamen sind nicht auf meinem Mist gewachsen. Ich habe sowieso keine Ahnung von Access. Es ist eine alte, aber noch funktionsfähige, Datenbank. Ich versuche nur einige Auswertungen noch zu bewerkstellingen. Irgendwann soll diese Anwendung auf einem SQL-Server laufen. Werde einige Sachen ausprobieren. Wenn nicht, dann muß ich mich in einem Access-Forum anmelden

Danke und schönes WE. Luckner

[jobo]

Zitat von Luckner:

die Tabellennamen sind nicht auf meinem Mist gewachsen. .. Ich versuche nur einige Auswertungen noch zu bewerkstellingen.

Ich kenne das, alte Anwendung, die niemand mehr haben will (also Entwickler), aber zäh sind. Das geht nicht gegen Dich, man kann sich selten gegen sowas wehren, außer man ist der Chef. Ich hab nur die Gelegenheit genutzt, es mal wieder los zu werden. Vielleicht bekommt es ja noch jemand mit.

Ach und grad erst gesehen, dbfiddle ist für Foren super, notfalls auch privat, wenn man grad kein XY DB da hat. Es gibt noch einige andere solche Online DB, die alle ihre Vor und Nachteile haben.
Oder z.B. auch Online SQL Formatierer, falls das eigene Tool es nicht kann. Ich persönlich finde das sehr hilfreich, formatierte SQL Statements zu lesen, spätestens, wenn sie nicht tun, was sie sollen. Ist ja im Programmcode auch nicht anders.

[mytbo]

Zitat von jobo:

Es gibt noch einige andere solche Online DB, die alle ihre Vor und Nachteile haben.

Wäre super, wenn du die Links hier posten könntest, einschließlich einer kurzen Beschreibung über die von dir empfundenen Vor- und Nachteile. Dafür würde es bestimmt einige geben.

Bis bald...
Thomas

[jobo]

OT
Hab ich hier ausgekoppelt:
https://www.delphipraxis.net/209971-...ksammlung.html

[mytbo]

Zitat von jobo:

Hab ich hier ausgekoppelt:
https://www.delphipraxis.net/209971-...ksammlung.html

Dafür von mir ein

Bis bald...
Thomas