SQL Der mehrteilige Bezeicher konnte nicht gebunden werden

PEASANT KING · 25. November 2011

Hallo Leute,

ich verstehe nicht wieso ich folgende Meldung beim Ausführen der SQL Anweisung bekomme:

Code:

UPDATE STUECKLI SET STUECKLI.xekpreis =(ARTSTAT.letzterek * STUECKLI.Anzahl)
FROM LAGER 
WHERE (STUECKLI.stueckarti = ARTSTAT.Artikelnum AND STUECKLI.artikelnum ='000002' AND STUECKLI.Art = 'M')

Die Meldung lautet Der mehrteilige Bezeichner "ARTSTAT.letzterek" konnte nicht gebunden werden.

Bin ich blind oder dumm ? Ich verstehe nicht warum es in die Hose geht.

Die Tabellen sind alle vorhanden, gleiches gilt für die jeweiligen Felder.

metzgore · 25. November 2011

Das FROM LAGER gehört schon mal nicht in ein Update-Statement.

PEASANT KING · 25. November 2011

Danke für den Tipp. Doch da muss ein FROM rein allerdings nicht LAGER sondern ARTSTAT.
Also war ich doch nur blind.
Es funktioniert!

Yuuri · 25. November 2011

Also in MySQL und SQLite kommt dort keinerlei FROM hinein.

http://www.mckoi.com/database/SQLSyntax.html#14

Nornenschwester · 25. November 2011

Da muss ich meinen Vorrednern recht geben, da kommt definitiv kein FROM hin!

PEASANT KING · 25. November 2011

Doch doch aber keine Panik ihr habt im Prinzip recht, allerdings kommt meine Abfrage innerhalb einer Makroprogrammiersprache vor, daher muss ich die Abfrage so gestalten.
SQL Syntaktisch ist es natürlich falsch.

Es handelt sich ausserdem um MSSQL

IceMatrix · 27. November 2011

Das SQL aus MSSQL sollte dringend gestrichen werden.

TheCadillacMan · 27. November 2011

IceMatrix schrieb:
Das SQL aus MSSQL sollte dringend gestrichen werden.

Wieso? (Der SQL-Dialekt vom Microsoft SQL Server heißt übrigens "Transact-SQL".)
Dass das "FROM" im "UPDATE" nicht zum Standard gehört ist klar, aber welche Datenbank hält sich schon an den SQL-Standard? Gerade den Marktführer Oracle interessiert der Standard doch auch nur wenn er keine Änderungen am eigenen System erfordert.

AlbertLast · 28. November 2011

Naja man sollte nicht Äpfel mit Birnen vergleichen.
T-SQL ist eine Procedural Language Erweiterung,
das hier gezeigte sql code ist kein t-sql.
T-SQL ist vergleichbar mit pl/sql und pl/pgsql.

Es gibt in dem Sinne auch nicht ein Standard,
es gibt mehrere Version von SQL(1) 87 bis SQL 2008 und
an neueren Version wird zurzeit gearbeitet.

Nach mein Wissen ist aber PostgreSQL und Oracle sehr nah am Standard.

yxcv · 28. November 2011

AlbertLast schrieb:
Naja man sollte nicht Äpfel mit Birnen vergleichen.
T-SQL ist eine Procedural Language Erweiterung,
das hier gezeigte sql code ist kein t-sql.
T-SQL ist vergleichbar mit pl/sql und pl/pgsql.
.

Wie kommst du denn zu dieser Mutmaßung?
Sicher ist das T-SQL!
Bei einem "UPDATE", das mehr als eine Tabelle auswertet, ist das "FROM" 100% korrekt.

Übrigens wäre es so am schnellsten.
Tabellen immer per JOIN und nicht per WHERE verbinden.

UPDATE STUECKLI
SET STUECKLI.xekpreis =(ARTSTAT.letzterek * STUECKLI.Anzahl)
FROM ARTSTAT
INNER JOIN STUECKLI
ON STUECKLI.stueckarti = ARTSTAT.Artikelnum
WHERE STUECKLI.artikelnum ='000002'
AND STUECKLI.Art = 'M'

AlbertLast · 28. November 2011

yxcv schrieb:
Wie kommst du denn zu dieser Mutmaßung?
Sicher ist das T-SQL!
Bei einem "UPDATE", das mehr als eine Tabelle auswertet, ist das "FROM" 100% korrekt.

Übrigens wäre es so am schnellsten.
Tabellen immer per JOIN und nicht per WHERE verbinden.

es fehlen für t-sql der declare und / oder begin teil
was eine Eröffnung des t-sql block darstellt.

deine zweite Aussage möchte an der Stelle auch anzweifeln,
über where zu joinen ist der alte style/standard.
Daher erkennen rdbms diese als join und werden gleichwertig ausgeführt
an Hand des Execution plan sollte sich das erkennbar machen.
Recht hast du dann wenn das rdbms diese where nicht als join erkennt,
was passieren kann.

yxcv · 28. November 2011

AlbertLast
T-SQL heißt "Transact Structured Query Language".
Es bedeutet also nicht, dass eine Prozedur oder Skript erstellt werden muss.
Das ist "lediglich" ein Zusatz des T-SQL.

...Daher erkennen rdbms diese ("Where") als "join" und werden gleichwertig ausgeführt.

Das ist falsch.
JOIN ist immer schneller als WHERE.
Dies ist auch ganz logisch, sobald verstanden wurde was und wie diese Befehle ausführen.

Wenn es keinen Zeitunterschied gibt, was bei Millionen Datensätzen und komplexen Datenbankstruktur
höchst selten der Fall ist, liegt das einzig und allein daran, dass der Datenbankmanager das Denken übernommen hat
und das Query intern optimiert wurde (Where zum Join umwandelt).

AlbertLast · 29. November 2011

Die Menge der Datensätze ist für den Query Planer egal,
dieser analysiert im ersten schritt das SQL und erkennt im where ein join
und damit wird es gleich behandelt, wie gesagt schau dir mal den Query Planer an.

Und man darf nicht vergessen das JOIN als solches erst in neuen sql standard drin ist,
vorher war joinen über where standard.

Suche

SQL Der mehrteilige Bezeicher konnte nicht gebunden werden

PEASANT KING

Commander

metzgore

Ensign

PEASANT KING

Commander

Yuuri

Fleet Admiral

Nornenschwester

Cadet 4th Year

PEASANT KING

Commander

IceMatrix

Lt. Commander

TheCadillacMan

Captain

AlbertLast

Lieutenant

yxcv

Gast

AlbertLast

Lieutenant

yxcv

Gast

AlbertLast

Lieutenant

Ähnliche Themen