Hallo Jörg, so weit ich weiß, gibt es in SQL kein Format für Datumsliterale. Deswegen schreibt man sie als String, typischerweise im ISO Format YYYY-MM-DD. Update: Im ODBC API gibt es die Schreibweise { *typ* '....' }, mit d (date), t (time) oder ts (timestamp) als Typ. Aber nur da. Ohne Anführungszeichen steht bei Dir 2021-01-01 und das ist ein numerischer Term, nämlich 2021 - 1 - 1 = 2019. Man müsste jetzt nachschlagen, was MYSQL tut, wenn es ein Datum mit einer Zahl vergleichen soll. Gerade MYSQL ist für sein großzügiges Type Juggling berüchtigt - andere SQLs hauen Dir das Statement eher um die Ohren. Möglicherweise gibt es in MYSQL eine Datumsdarstellung der Form "Tage seit Stichtag x" - wie bspw. in Excel, wo es Tage seit 1904 oder 1900 sind - und er konvertiert das Datum in diese Darstellung. Tage seit 190x ist eine recht hohe Zahl, selbst Tage seit dem UNIX time_t Stichtag 1970 ist schon fünfstellig. Und damit würde dann wohl außen jeder Satz deiner DB getroffen und im Subselect keiner. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, so weit ich weiß, gibt es in SQL kein Format für Datumsliterale. Deswegen schreibt man sie als String, typischerweise im ISO Format YYYY-MM-DD. Ohne Anführungszeichen steht da 2021-01-01 und das ist ein numerischer Term, nämlich 2021 - 1 - 1 = 2019. Man müsste jetzt nachschlagen, was MYSQL tut, wenn es ein Datum mit einer Zahl vergleichen soll. Gerade MYSQL ist für sein großzügiges Type Juggling berüchtigt - andere SQLs hauen Dir das Statement eher um die Ohren. Möglicherweise gibt es in MYSQL eine Datumsdarstellung der Form "Tage seit Stichtag x" - wie bspw. in Excel, wo es Tage seit 1904 oder 1900 sind - und er konvertiert das Datum in diese Darstellung. Tage seit 190x ist eine recht hohe Zahl, selbst Tage seit dem UNIX time_t Stichtag 1970 ist schon fünfstellig. Und damit würde dann wohl außen jeder Satz deiner DB getroffen und im Subselect keiner. _Rolf_ -- sumpsi - posui - obstruxi