SQL-Abfrage will nicht mehr

[begga]

Folgende SQL-Abfrage funktioniert einwandfrei unter MySQL 3 und 4

SELECT ideenmanagement.id, memberid, username, autor, email, betreff, MAX( ideenverlauf.status ) , ideenmanagement.timestamp
FROM ideenmanagement, ideenverlauf
LEFT JOIN members ON ideenmanagement.memberid = members.id
WHERE ideenmanagement.id = ideenverlauf.ideenid
GROUP BY ideenmanagement.id
ORDER BY TIMESTAMP DESC

Aber auf einer MySQL-Datenbank der Version 5 wird der Dienst mit folgender FM verweigert:

#1054 - Unknown column 'ideenmanagement.memberid' in 'on clause'

Ich blicke da nicht durch. Warum ist das so?

 

[dms]

Keine Ahnung ob sich da was geändert hat, aber ich verwende LEFT JOINs immer mit Klammern:

LEFT JOIN members ON (ideenmanagement.memberid = members.id)

Versuchs mal so.

 

[wegus]

SQL-Abfrage will nicht mehr

SQL-Interpreter sind ausgesprochen unemotional! Mag sein das die Abfrage nicht mehr funktioniert - mit "wollen" hat das sicher nichts zu tun!

Unknown column 'ideenmanagement.memberid' in 'on clause'

Gibt es denn die Spalte, stimmen die Zugriffsrechte für den SQL-User auf diese Tabelle? Die Fehlermeldung würd ich erstmal wörtlich nehmen und davon ausgehen das er die Spalte wirklich nicht auflösen kann.

Di verwendest mal qualifizierte Spaltenbezeichner (Tabelle.Spalte), mal nicht. Mach das doch mal einheitlich bei allen Spalten! Oftmals macht e auch Sinn einen Alias für die Tabellennamen zu definieren

FROM ideenmanagement as im, ideenverlauf as iv


und dann die Spalten mit den Aliases voll zu qualifizieren.

Der Join ist ja auch schön und gut, aber durch das FROM mit 2 Tabellen geht dem ganzen ein implizites Kreuzprodukt der Tabellen voraus. Sicher das da Spaltenbezeichner nicht mehrfach Verwendung finden?

 

[begga]

Keine Ahnung ob sich da was geändert hat, aber ich verwende LEFT JOINs immer mit Klammern:

LEFT JOIN members ON (ideenmanagement.memberid = members.id)

Versuchs mal so.

Macht leider keinen Unterschied...

 

[ruerueka]

schon gelesen?
http://dev.mysql.com/doc/refman/5.0/en/left-join-optimization.html

 

[begga]

SQL-Interpreter sind ausgesprochen unemotional! Mag sein das die Abfrage nicht mehr funktioniert - mit "wollen" hat das sicher nichts zu tun!

Das ist mir schon klar...

Gibt es denn die Spalte, stimmen die Zugriffsrechte für den SQL-User auf diese Tabelle?

Beides ja! Hab die Tabellen 1:1 von v4 auf v5 migriert.

Di verwendest mal qualifizierte Spaltenbezeichner (Tabelle.Spalte), mal nicht. Mach das doch mal einheitlich bei allen Spalten! Oftmals macht e auch Sinn einen Alias für die Tabellennamen zu definieren

FROM ideenmanagement as im, ideenverlauf as iv
und dann die Spalten mit den Aliases voll zu qualifizieren.

Du weisst doch, Programmierer sind faul.
Dort wo ich's nicht brauch, mach ichs auch nicht...

Der Join ist ja auch schön und gut, aber durch das FROM mit 2 Tabellen geht dem ganzen ein implizites Kreuzprodukt der Tabellen voraus. Sicher das da Spaltenbezeichner nicht mehrfach Verwendung finden?

Ja, sicher. Ausserdem dürfte die FM dann ja nicht "unknown column" sein sondern "ambiguous column" oder sowas in der Art.

 

[wegus]

Dort wo ich's nicht brauch, mach ichs auch nicht.

ach so

 

[begga]

schon gelesen?
http://dev.mysql.com/doc/refman/5.0/en/left-join-optimization.html

Gerade jetzt! Danke!

Mit

from ideenverlauf, ideenmanagement

anstatt

from ideenmanagement, ideenverlauf

gehts jetzt.
Warum das so ist werd ich gleich mal in Ruhe nachlesen müssen...

 

[ruerueka]

aus der doku, s.o:

NOTE: You will get "UNKNOWN COLUMN NAME" errors
unless you make sure you precede the left_join_clause
with the primary table name you are joining to.

Du solltst also mit der Reihenfolge der Tabellen rumspielen.
Auf anderen Plattformen hilft es auch, Klammern zu setzen, alse

 a, ( b left join c on b.xx=c.yy)

Meiner Meinung nach darfst du in der ON Clause nur auf Felder der Tabellen b und c zugreifen, du greifst aber auf a und c zu, wenn ich das richtig sehe. Die Felder aus a sind aber nicht sichtbar. ==> Komplettes Statement umformulieren, evtl. hilft dir ein subselect, ich weiss ja nicht, was du genau willst, weil ich das Datenmodell nicht kenne.

EDIT: war mal wieder zu langsam...

 

[begga]

EDIT: war mal wieder zu langsam...

Macht ja nix, trotzdem Danke!
Subselect wär zu einfach
Das Statement ist geschätzte 6 Jahre alt, da gabs auf MySQL noch keine Subselects.
Hatte mich nur gewundert warum das nach der Migration auf MySQL 5 nicht mehr läuft...

 

[wegus]

ruerueka hat IMHO völlig recht!

wie geschrieben ist FROM ideenmanagement, ideenverlauf ein FULL JOIN - nur eben implizit. Das kann man machen, sollte dann aber Alles über implizite Joins mit Beschränkungen in der WHERE-Clause machen.

Das mixen von impliziten und expliziten JOINs kann zu solch abstrusen ergebnissen führen. Daher qualifiziere ich eben immer alle Bezeichner und allein dadurch fällt sowas schneller ins Auge! Faul sein ist ja schlau, wenn man weiß wo man faul sein darf und wo man es nicht sein sollte

 

[ruerueka]

mysql war ja früher überhaupt nicht kompatibel zum Standard und hat auch bei den Joins eigenes Verhalten an den Tag gelegt. Wenn du jetzt also von 3.23 oder 4 auf 5 gehst, wird es noch an anderen Stellen Ärger geben.
Ich liebe die Doku ;-)
http://dev.mysql.com/doc/refman/4.1/en/join.html
Hier ein Auszug (ja, er ist aus der 4er Doku, siehe Link):

Note that several changes in join processing were made in MySQL 5.0.12 to make MySQL more compliant with standard SQL. These changes include the ability to handle nested joins (including outer joins) according to the standard. If a nested join returns results that are not what you expect, please consider upgrading to MySQL 5.0. Further details about the changes in join processing can be found at http://dev.mysql.com/doc/refman/5.0/en/join.html.

 

[begga]

Entwickelt hab ich damals auf 3.23
Beim Wechsel auf 4.025 gabs kein Problem.
Sieht so aus als würden jetzt 2 Statements beim Wechsel auf 5.0.51 nicht mehr klappen.
Der Rest läuft Gott sei dank...