AS Syntax - MSSQL
Hallo,
ich versuche ein SQL Befehl an die DB zu schicken.
SELECT [AccountId], ( 6371 * acos( cos( radians(37) ) * cos( radians( [New_latitude] ) ) * cos( radians( [New_longitude] ) - radians(-122) ) + sin( radians(37) ) * sin( radians( [New_latitude] ) ) ) ) AS distance FROM [tw_elektric_MSCRM].[dbo].[Account] HAVING distance < 25 ORDER BY distance
Leider kommt due Meldung, dass das Feld distance nicht vorhanden ist.
Ich lege dies ja auch nur virtuell mit AS an.
Was mache ich falsch?
Danke
Gruß
ottscho
ich versuche ein SQL Befehl an die DB zu schicken.
SELECT [AccountId], ( 6371 * acos( cos( radians(37) ) * cos( radians( [New_latitude] ) ) * cos( radians( [New_longitude] ) - radians(-122) ) + sin( radians(37) ) * sin( radians( [New_latitude] ) ) ) ) AS distance FROM [tw_elektric_MSCRM].[dbo].[Account] HAVING distance < 25 ORDER BY distance
Leider kommt due Meldung, dass das Feld distance nicht vorhanden ist.
Ich lege dies ja auch nur virtuell mit AS an.
Was mache ich falsch?
Danke
Gruß
ottscho
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 144651
Url: https://administrator.de/contentid/144651
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
11 Kommentare
Neuester Kommentar
Soweit ich weiß gehts mit dem Anzeigenamen nicht, aber man kann auch die Spalte angeben, nach der Sortiert werden soll (bei Dir die 2. Spalte):
SELECT [AccountId], ( 6371 * acos( cos( radians(37) ) * cos( radians( [New_latitude] ) ) * cos( radians( [New_longitude] ) - radians(-122) ) + sin( radians(37) ) * sin( radians( [New_latitude] ) ) ) ) AS distance FROM [tw_elektric_MSCRM].[dbo].[Account] HAVING distance < 25 ORDER BY 2
--> HAVING distance < 25 ORDER BY distance
Warum benutzt du HAVING, wenn du keine GROUP BY CLAUSE verwendest ? Versuche es mal mit einer "normalen" WHERE CLAUSE, HAVIN OHne ein GROUP BY wirft dir einen Fehler
--> WHERE distance < 25 ORDER BY distance
Na ja...HAVING ist hier einfach ...falsch ...Hast du es mal mit einem WHERE probiert ?.. BTW, welche DB hast du eigentlich ? Im Titel steht MSSQL, aber du zitierst aus dem MYSQL Handbuch ?
Gruss
Hallo,
Ich kenne MSSQL gar nicht, aber in Oracle kannst du keinen ALIAS im WHERE verwenden in deinem Fall. Du musst als im WHERE die Berechnung nochmals aufführen. Der Grund ist, das das Filtern über die WHERE Clause vor der Berechnung des SELECT Statements erfolgt.
Gruss
Ich kenne MSSQL gar nicht, aber in Oracle kannst du keinen ALIAS im WHERE verwenden in deinem Fall. Du musst als im WHERE die Berechnung nochmals aufführen. Der Grund ist, das das Filtern über die WHERE Clause vor der Berechnung des SELECT Statements erfolgt.
SELECT [name], ( 6371 * acos( cos( radians(48.06223) ) * cos( radians( [New_latitude] ) ) * cos( radians( [New_longitude] ) - radians(8.52301) ) + sin( radians(48.06223) ) * sin( radians( [New_latitude] ) ) ) ) AS distance
FROM [tw_elektric_MSCRM].[dbo].[Account]
WHERE ( 6371 * acos( cos( radians(48.06223) ) * cos( radians( [New_latitude] ) ) * cos( radians( [New_longitude] ) - radians(8.52301) ) + sin( radians(48.06223) ) * sin( radians( [New_latitude] ) ) ) ) < 25
ORDER BY 2
Gruss
Man sollte immer alles durchlesen
Having ohne group By geht tatsächlich nicht und where 2 < 25 ist natürlich nicht richtig, weil immer wahr.
Und man kann nur bei order by die Spaltennummer angeben.
So wie es db-wizard gemacht hat, sollte es tun.
Laut MSSQL Handbuch sollte aber auch Deine Variante mit dem Aliasnamen tun.
Having ohne group By geht tatsächlich nicht und where 2 < 25 ist natürlich nicht richtig, weil immer wahr.
Und man kann nur bei order by die Spaltennummer angeben.
So wie es db-wizard gemacht hat, sollte es tun.
Laut MSSQL Handbuch sollte aber auch Deine Variante mit dem Aliasnamen tun.
Moin alle,
die Varianten mit ALIAS und der unkonventionellen Interpretation (oder Implementierung) der HAVING-Clause funktionieren in der Tat nur unter mySQL.
Und das steht auch dort ein bisschen versteckt im Handbuch, so als wären doe Entwickler sich nicht ganz sicher, ob sie da nun stolz drauf sein dürften.
[Zitat]
[/Zitat]
Quelle: Ein willkürlich herausgegriffenes mySQL-Manual
--> Das ist je nach Sichtweise
a) ein nützliches Feature
b) absolut indiskutabel, weil strunzinkompatibel, sollte jemals das darunterliegende Datenbankblech geändert/getauscht werden.
Und es verstehen ncht mal SQL-Kundige, warum es funktioniert haben könnte.
Meine Sichtweise tendiert eindeutig zu b).. BTW haben wir uns ja gerade wegen dieser Inkompatibilität hier im Thread getroffen.
A propos Inkompatibilitäten:
könntet ihr bei Gelegenheit (in der Halbzeitpause oder so) bitte noch ein bisschen nach-editieren auf ?
Und evt. auch ein paar gezielte Zeilenumbrüche reinhacken in das Statement, das sonst nur ein 32-Bit-Parser zu lesen gewillt wäre?
Oder ein Biber nach 32 Bit?
Grüße
Biber
die Varianten mit ALIAS und der unkonventionellen Interpretation (oder Implementierung) der HAVING-Clause funktionieren in der Tat nur unter mySQL.
Und das steht auch dort ein bisschen versteckt im Handbuch, so als wären doe Entwickler sich nicht ganz sicher, ob sie da nun stolz drauf sein dürften.
[Zitat]
...
{zum Thema AS - Aliase in GROUP BY/Having verwenden}
Einem Ausdruck select_expr lässt sich mit AS alias_name ein Alias zuweisen. Der Alias wird als Spaltenname des Ausdrucks benutzt und kann in GROUP BY-, ORDER BY- oder HAVING-Klauseln verwendet werden
....
...
{zum Thema HAVING auf NICHT-GROUP-BY-Spalten]
...
Die HAVING-Klausel wird fast als Letztes angewandt – unmittelbar bevor die Elemente an den Client gesendet werden, und ohne Optimierung. (Nur LIMIT wird noch nach HAVING angewandt.)
Der SQL-Standard sieht vor, dass HAVING nur Spalten in der GROUP BY-Klausel oder solche Spalten referenzieren darf, die in Zusammenfassungsfunktionen verwendet werden. Allerdings unterstützt MySQL eine Erweiterung dieses Verhaltens und gestattet HAVING ferner die Referenzierung von Spalten in der SELECT-Liste und Spalten in äußeren Unterabfragen.
...
Quelle: Ein willkürlich herausgegriffenes mySQL-Manual
--> Das ist je nach Sichtweise
a) ein nützliches Feature
b) absolut indiskutabel, weil strunzinkompatibel, sollte jemals das darunterliegende Datenbankblech geändert/getauscht werden.
Und es verstehen ncht mal SQL-Kundige, warum es funktioniert haben könnte.
Meine Sichtweise tendiert eindeutig zu b).. BTW haben wir uns ja gerade wegen dieser Inkompatibilität hier im Thread getroffen.
A propos Inkompatibilitäten:
könntet ihr bei Gelegenheit (in der Halbzeitpause oder so) bitte noch ein bisschen nach-editieren auf ?
Und evt. auch ein paar gezielte Zeilenumbrüche reinhacken in das Statement, das sonst nur ein 32-Bit-Parser zu lesen gewillt wäre?
Oder ein Biber nach 32 Bit?
Grüße
Biber