Datenbank: Firebird • Version: 2.1 • Zugriff über: Delphi/IBDAC
Frage zu JOIN
Hallo,
ich habe folgende Abfrage: with DM1.DataModule1.IBCArtikelQuery do begin Close; SQL.Clear; SQL.Add('select A.*,E.EINHEIT,W.WARENGRUPPE,L.FIRMA,L.KREDITORENNR '); SQL.Add('from ARTIKEL A '); SQL.Add('left outer join EINHEITDB E on A.VERPEINHEIT=E.EID '); SQL.Add('left outer join EINHEITDB E on A.VERBRAUEINHEIT=E.EID '); SQL.Add('left outer join EINHEITDB E on A.LAGBESTEINHEIT=E.EID '); SQL.Add('left outer join EINHEITDB E on A.MINBESTEINHEIT=E.EID '); SQL.Add('left outer join WARENGRUPPEDB W on A.WARENGRUPPE=W.WID '); SQL.Add('left outer join LIEFERANT L on A.LIEFERANT1=L.LID '); ExecSQL; end; Diese meldet bei der zweiten (und natürlich den folgenden) "left outer join" folgenden Fehler: "Alias E conflicts with an alias in the same statement". Ok...soweit klar, woher der Fehler kommt. Eine Lösung ist, das E in den weiteren statements durch andere Buchstaben zu ersetzen - aber irgendwie nicht sonderlich elegant. Hat jemand noch eine andere ("elegantere") Lösung? Insbesondere in Hinsicht auf eine mögliche, zukünftige "Vermehrung" der Einheiten-Felder, wird es irgendwann unübersichtlich... Hartmut |
AW: Frage zu JOIN
Wenn du mehrfach einen Join mit einer Tabelle machen möchtest, musst du jedes mal einen anderen Alias benutzen.
|
AW: Frage zu JOIN
Ich nummeriere die Aliase nötigenfalls durch, wenn ich dieselbe Tabelle mehrfach hinzujoine (E1, E2, E3 usw.). Aber könnte man in Deinem Fall die Verknüpfungsbedingungen nicht einfach verodern?
SQL-Code:
left outer join EINHEITDB E on A.VERPEINHEIT=E.EID OR A.VERBRAUEINHEIT=E.EID OR A.LAGBESTEINHEIT=E.EID OR A.MINBESTEINHEIT=E.EID
|
AW: Frage zu JOIN
Die Frage ist, was willst Du mit dieser Abfrage erreichen?
Zu jedem Artikel so vorhanden die/den Lieferanten, die Warengruppe(n) ausgeben, soweit so klar. Aber was soll bei den Einheiten passieren? Auf welche Einheit soll sich Dein E.Einheit beziehen? Formuliere bitte einmal in Worten, was Du erreichen möchtest und was Dir gegeben ist. Dann läßt sich sicherlich eine mehr oder minder elegante Lösung finden. |
AW: Frage zu JOIN
Zitat:
Es gibt keine andere Lösung, jeder Alias (sowohl einer Tabelle, als auch eines Feldes) muss eindeutig benannt sein. Es ergibt auch sonst keinen Sinn. Und damit zu Deinem Statement. Stellt man sich vor, in Deinem Statement stünden eindeutige Aliase, was würde es dann für einen Sinn ergeben? Vielleicht ist Dir die Join-Thematik nicht richtig klar? Oder Du hast ein unglückliches Datenmodell vorliegen? Aliasnamen Wenn ich Tabellen mehrfach einbinde, wähle ich den Alias ("entgegen" des Tabellennamens) so, dass er die Menge beschreibt, die ich dort aufbaue bzw. abgreifen will. Dabei stelle ich u.U. auch den praktischen Nutzen eines möglichst kurzen Alias hinten an. |
AW: Frage zu JOIN
Hallo,
vielleicht ist es eine gute Idee, das SQL Statement erst einmal im Management Studio der DB aufzubauen, zu testen und wenn alles korrekt ist, das Ding dann nach Delphi zu bringen! Gruß |
AW: Frage zu JOIN
Zunächst mal danke für eure Ideen/Anregungen. Wie ich bereits geschrieben habe, ist ein jeweils anderer Alias möglich...aber aus meiner Sicht unschön - und wenn's mehr Einheiten-Felder werden, auch irgendwann mal unübersichtlich.
Um nochmal zu verdeutlichen, warum ich das so mache: in der ARTIKEL-Tabelle habe ich verschiedene Angaben (Anzahl im Lager, Mindestanzahl, Anzahl je Bestelleinheit, etc.), die jeweils mit einer Zahl in einem Feld und mit der zugehörigen Einheit (also Stück, Karton, Rolle, etc.) bzw der ID in einem anderen Feld aus der EINHEITEN-Tabelle (das ist dann der EID) hinterlegt werden. Um beim Anzeigen nicht die ID der Einheit sondern die Einheit im Klartext anzuzeigen, muss ich dass natürlich für jedes Feld auslesen und zuordnen. Also: ja es geht mit verschiedenen Alias (so habe ich das aktuell auch gelöst), aber ich habe mich eben gefragt, ob es nicht eine elegantere/einfachere/bessere Lösung gibt? Hartmut |
AW: Frage zu JOIN
Irgendwie wird aber dann doch nicht klar, wenn du die so ggf. ermittelte Einheit nur 1x anzeigst, zu welcher Menge aus den Artikel sie gehört (Lagermenge, Mindestanzahl usw).
Hinzu kommt, dass so ein Artikel mehrfach angezeigt wird, wenn er in mehreren Spalten mit der Einheiten-Tabelle gejoined wird un in mehreren Spalten auch Einträge hat. So bekäme man nur 1 Datensatz pro Artikel SQL.Add('select A.*,E1.EINHEIT as Verpackungseinheit,E2.Einheit as Verbrauchseinheit,');//... SQL.Add('W.WARENGRUPPE,L.FIRMA,L.KREDITORENNR'); SQL.Add('from ARTIKEL A '); SQL.Add('left outer join EINHEITDB E on A.VERPEINHEIT=E.EID '); SQL.Add('left outer join EINHEITDB E on A.VERBRAUEINHEIT=E.EID '); |
AW: Frage zu JOIN
Zitat:
Und nochmal, solange mehrfach auf die Einheit referenziert wird, gibt es keine andere Möglichkeit. Zumindest nicht in dieser Darstellungsform. Erst wenn man die Artikel Attribute (alle Einheitsangaben und sonstige) transformiert und in Listenform ausgibt, könnte man mit einem Join verschiedene Einheiten reinjoinen. Die Transformation der Artikelattribute ist aber dann auch schon ein großer Anlauf. Das wäre ggF. sinnvoll, wenn man es -jenachdem - mit sehr unterschiedlichen Artikeln zu tun hat und deren Attribute standardmäßig als separate Tabelle modelliert. Ich glaube in diversen Webshops wird das gern mal so gemacht. Das hat aber wieder eine Gegenindikation, bei der Suche nach Artikeln über verschiedene Attribute. |
AW: Frage zu JOIN
ich lehn mich mal weit aus dem Fenster:
SQL-Code:
das soll bedeuten, gib die gerade aktuelle Mengeneinheit aus (bei Ballen ist Stk null usw.)
select A.*,E.EINHEIT,W.WARENGRUPPE,L.FIRMA,L.KREDITORENNR
from ARTIKEL A left outer join EINHEITDB E on A.VERPEINHEIT=E.EID left outer join EINHEITDB E on A.VERBRAUEINHEIT=E.EID left outer join EINHEITDB E on A.LAGBESTEINHEIT=E.EID left outer join EINHEITDB E on A.MINBESTEINHEIT=E.EID left outer join WARENGRUPPEDB W on A.WARENGRUPPE=W.WID left outer join LIEFERANT L on A.LIEFERANT1=L.LID Richtig geraten? Gruß K-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz