MONTH und YEAR Funktion

[Frank ter Duis]

Hi Leute, <br><br>
bei folgendem SQL bekomme ich die Fehlermeldung (umsatztag ist Typ Date)<b>"Ungültiges Schlüsselwort MONTH(f1.umsatztag)"</b>: <br><br>

SELECT DISTINCT f1.umsatztag, <br>
f2.umsatz as F_10001, f3.umsatz as F_10002, f4.umsatz as F_10003
FROM umsatz f1<br>
left outer join umsatz f2 on f2.umsatztag = f1.umsatztag and f2.filialnummer = 10001 <br>
left outer join umsatz f3 on f3.umsatztag = f1.umsatztag and f3.filialnummer = 10002<br>
left outer join umsatz f4 on f4.umsatztag = f1.umsatztag and f4.filialnummer = 10003 <br>
WHERE MONTH(f1.umsatztag) = 02 and YEAR(f1.umsatztag) = 2002<br>
<br>
MONTH und YEAR sind doch gültige SQL Functionen. Ich habe ein bisschen den Verdacht das MONTH und Year ziemlich neue SQL-Functionen sind und in meiner Version noch nicht unterstützt werden (Delphi 4 Prof.). Wie bekomme ich meine SQL-Version raus bzw. wo bekomme ich ein Update dafür?<br><br> Danke Jungs und Mädels<br><br> CU Frank

[Frank ter Duis]

Eins ist mir noch aufgefallen. Ich benutze das SQL in einer TQuery-Komponete von Delphi 4 Prof. Wenn ich das SQL im DatenbankExplorer aufrufe läuft es. Find ich irgendwie seltsam... Tippfehler sind ausgeschlossen, da ich das SQl-Statment 1 vs 1 kopiere

[Andreas Kosch]

Hallo,

um welche Datenbank geht es hier? Da TQuery genannt wurde, ist die BDE im Spiel und die BDE unterstützt je nach Alias-Konfiguration entweder LOCAL SQL oder SERVER SQL (siehe <b>SQLQRYMODE</b>)

[Frank ter Duis]

Aber wenn ich das mal mit meinem jugendlichen, unwissenden Leichtsinn sagen darf: <b> Ich dachte der grosse Vorteil von SQL ist das Plattform-/ Datenbankunabhänige. Und in meinen Augen ist SQL = SQL bis auf evtl ein paar BS bzw DB-Speziefischen Funktionen</b><br><br>
Nur DAY, MONTH und YEAR sind "ganz normale" SQL-Functionen lt. SQL92 (oder wie auch immer dieser Standart heisst). <br><br><br> Wie gesagt, im Datenbankexplorer läufts und auf der DEC und der AS/400 hab ich diese Functionen auch schon benutzt....
<br><br> PS: in meiner Konfiguration steht der SQLQRYMODE auf LOCAL SQL (Was ist zwischen den Einstellungen der Unterschied?

[Andreas Kosch]

Hallo,

&gt;Ich dachte der grosse Vorteil von SQL ist das Plattform-/ Datenbankunabhänigkeit...

in diesem Spiel sind verschiedene Karten im Umlauf: <br>
a) SQL-Standard (SQL89, SQL 92, jeweils Entry Level 1,2 oder 3) <br>
b) SQL-Datenbank (also ein echter SQL-Server, der sich auf einen SQL-Standard bezieht) <br>
c) LOCAL SQL der BDE (also eine SQL-Simulation)

Borland hat zu keinem Zeitpunkt gesagt, dass die SQL-Simulation der BDE zu einem der SQL-Standards konform ist. Wenn die BDE-Konfiguaration SQLQRYMODE auf LOCAL SQL steht, erhält die BDE den Auftrag, sich um die Abarbeitung des SQL-Jobs zu kümmern. Daher steht nur das zur Verfügung, was die BDE im eigenen LOCAL SQL-Sprachumfang dokumentiert (siehe Hilfedatei <i>LOCALSQL.HLP</i> aus dem BDE-Verzeichnis).

Nur dann, wenn ein echter SQL-Server im Spiel ist und somit keine Middleware (BDE oder MS Jet Engine etc.) eingebunden wird, kann man von einer Basismenge universeller SQL-Funktionen gemäss Standard ausgehen

[Andreas Tengicki]

>kann man von einer Basismenge universeller SQL-Funktionen gemäss Standard ausgehen.

Dies ist richtig und eine gschickte Formulierung das nur sehr eingeschränkt von einem Standard zu sprechen ist. Spätestens wenn man mit Optimierungen auf Performance (oder so) beginnt, kocht jeder seine eigene Suppe. Denn meist gibt es geschickte und ungeschickte SQL Statements.

Beipiel: Nested Select ist meist gut zu lesen, und bei update Statement teilweise notwendig. Es ist aber auch ein sicherer Weg Interbase (5) in die Knie zu zwingen. Oracle macht es einfach