SELECT * FROM tbl_buchhaltung B where b.jahr between '1.1.2022' and '31.12.2022'
Nur der Vollständigkeit halber:
Das funktioniert nur dann sicher, wenn es kein DateTime-Feld mit Time-Daten ist. Datensätze mit einem Datum am 31.12.2022 ab 00:00:01 Uhr werden von der Abfrage nicht berücksichtigt.
ja, aber ist noch ein wenig komplizierter, weil es auch noch unterschiede zwischen dialekt 1 und dialekt 3 geben kann
in dialekt 1 gibt es nur datentyp date, der entgegen seinem namen trotzdem ein timestamp ist, also auch die zeit beinhaltet
im dialekt 3 heisst der gleichartige timestamp, date ist dann nur datum, time nur die zeit
konstanten wie current_date kann man da immer drin unter bringen, im timestamp bzw alten dialekt 1 date datentyp ist das dann das akuelle datum mit 0:00 uhr morgens
wenn es also im o.a. beispiel ein timestamp gewesen wäre, dann wäre das anders (war es aber gar nicht, dachte ich wohl nur, aber walter hat da wohl nur die jahreszahl drin gespeichert, warum auch immer
das ann ein problem ist, das mit der akuellen Jahreszahl zu vergleichen, aber das ist ja gelöst)
AAusgehend davon das das feld im dialekt 3 (egal ob date oder timestamp) innerhalb der o.a. between anweisung abgefragt wird und
der Wert aus current_date beim speichern als default gesetzt wird, würde das passen.
konsequent für timestamps wäre also
...where datum >='1.1.2022' and datum <1.1.2023'
weil darüber auch alle timestamps am letzten Tag des Jahres dazwischen wäre inkl millisekunden vor neujahr, mit extract ist das aber eleganter lösbar.
für diejenigen, die sich fragen, wie das mit datetime/timestamp/etc überhaupt funktioniert und warum man da werte einfach addieren usw. kann,
es gibt immer einen Tag 0, bei firebird zB der 30.12.1899
seit dem sind so viel tage vergangen
select datediff(day,cast('30.12.1899' as date),current_date) from rdb$database
ergebnis 44851
wer also technisch das datum 17.10.2022 speichern will braucht nur diesen integer wert (date datentyp in dialekt 3 mit 4 Byte länge)
wer das als datetime speichern will, nimmt dafür ja den timestamp datentyp im
fb dialekt 3 oder date im dialekt 1 (beide 8 Byte)
und für die uhrzeit wird der anteil, der vom tag vergangen ist, dann als nachkommstelle dahinter gesetzt
17.10.2022 12:00 = 44851,5
17.10.2022 18:00 = 44851,75
Der Engine intern ist es völlig egal, welcher tag/monat/jahr dahinter steht und ob es schaltjahr oder nicht ist. wenn man das
korrekt angeeigt haben will, wovon man ausgehen kann, dann wird die o.a. zahl eben in die Notation umgerechnet, mit der man
üblicherweise Zeitpunkt darstellt.
im Firebird
sql kann ich daher auch datum + x rechnen usw. und wenn man als String dann zB
select * from tabelle where datum='17.10.2022'
abfragt, dann baut die engine aus dem string erst mal die zahl und wenn das laut encoding passt, wird das intern also die o.a. zahl.
wenn das nicht passt, wie zum Beispiel das hier, dann gibt es in Firebird eine
exception
select * from tabelle where datum='30.02.2022'
das macht keineswegs jede Datenbank identisch,
mysql war zum beispiel mal bekannt dafür, das man dort eben auch den 30.2. speichern konnte.
wie Jasocul schon schrieb, es muss immer berücksichtigt werden, was in den Datentypen drin sein könnte, damit ihr nicht mal irgendwann
für so was wie den lustigen exchange bug von anfang 2022 (However, this variable signed int32 can store only a maximum value of
2,147,483,647, which is less than the new date value of 2,201,010,001 for January 1st, 2022, at midnight) oder ein fieser Bug
beim Jahrausendwechsel in crystal reports, der sich auch da erst ende Februar im jahr 2000 auswirkte, weil die engine meinte,
das es kein Schaltjahr wäre, weil die Jahreszahl 2000 durch 100 teilbar ist, was die Regel dafür ist, das Schaltjahre ausfallen
können, dummerweise wusste man bei crystalreports dann wohl nichts von der ergänzenden Regel, das die 100 Jahr regel alle 400 Jahre
ausfällt, also im Jahr 2000 das doch kein ausfallendes Schaltjahr gab.
Crystal reports hat da aufgrund irgendwelcher eigenen Umrechnungsroutine also freundlicherweise schon auf allen Dokumenten am 29.2.2000
das Datum 1.3.2000 draufgedruckt. Das hat so manche Buchhaltungsabteilung hektisch werden lassen