Realzahl in Datum wandeln SQLLite

[jobo]

Zitat von Emsbootsmann:

...Nun möchte ich bei der Suche im Edit1.text
"17.03" eingeben und dann soll er diesen Datensatz finden. Dafür müsste ich den Realwert in Datum wandeln aber wie.

Meine Vorgehensweise aus verschiedenen Gründen.
Das Teildatum so anreichern, dass es ein gültiges Datum ergibt und zwar den Start einer Bereichssuche, korrespondierend einen 2.Wert bauen, der das Ende des Bereiches darstellt.
Ergibt für einen Tagesbereich bspw. solch ein Statement:

Code:

  //delphi pseudocode
  Var startDateRange, endDateRange :TDate
  begin
    startDateRange := EditText+'.2016';
    endDateRange := startDateRange + 1 Tag;

Code:

  --SQL Statement
select * from  mytable x where x.mydate between :pStartDate and :pEndDate

Die Anreicherung und Konvertierung des Eingabestrings kann man natürlich auch im SQL Statement selbst durchführen.
Wichtig ist, bestimmte Prinzipien zu berücksichtigen.
Kein Like, sondern Bereichssuche mit ><= oder between im SQL.
Bereichserzeugung (Parameterwerte) geht idR recht einfach, sobald man echte Datumswerte erzeugt hat, dann kan man damit einfach rechnen, das gilt sowohl für SQL als auch für Delphi. In SQL stehen dazu -meist Datenbank spezifisch- eine ganze Reihe von Hilfsfunktionen zur Verfügung.

[p80286]

Nun der Wunsch nach dem "17.3" ist als solches ja schon seltsam.
Meiner Meinung nach müßte man den 17.3.2015,17.03.2016 (oder besser 2015-03-17,2016.03.17) usw. suchen.
Das "Like " sehe ich als berechtigte Visualisierung eines vergewaltigten DB-Feldes.

Gruß
K-H

[nahpets]

Zitat von p80286:

Das "Like " sehe ich als berechtigte Visualisierung eines vergewaltigten DB-Feldes.

Diese Formulierung gefällt mir

Hier ist eigentlich noch die Aufgabenstellung unklar.

Wenn nach 17.03 gesucht wird, heißt das, dass alle Datensätze zu allen 17.03 aller Jahre gefunden werden sollen?
Oder will man hier dem Anwender nur die Eingabe von 5 weiteren Zeichen ersparen, also eine unsinnige Faulheit unterstützen?

Dann scheidet das von Jobo zu Sprache gebrachte Between leider aus.

Wenn man nach einem Datum sucht, dann sollte man auch dieses Datum eingeben und nicht nur 'ne Teilmenge, in der Hofflung: Die DB wird's schon richten.

Alternative: Datum als Zeichenfolge in der DB ablegen in der Form YYYYMMDD. Dann kann man auch mit Teilzeichenfolgen und Between sinnvoll und (vermutlich) performant suchen.

Aus der Eingabe 2017 wird dann per Programmcode Between '20170101' and '20171231'.

Aus der Eingabe von 201703 wird Between '20170301' and '20170331'.

So kann man sinnvoll nach einem konkreten Datum suchen oder auch nach Datumsbereichen von-bis.

Die einzige Verwendung von Eingaben ala 17.03 erscheint mir bei einer Kalendersuche die Suche nach bestimmten Jahrestagen zu sein. Sowas in der Art: Wer ist alles am 17.03 geboren.

Also sowas: http://www.promi-geburtstage.de/maer...g-am-17-maerz/
https://geboren.am/17-maerz

[hoika]

Hallo,
warum sollte die Aufgabenstellung seltsam sein?

Den Bug habe ich am 17.03. eingebaut, aber welches Jahr ... ?

Noch mal zum Thema:
select * from tabelle where strftime('dd.mm',Datumsspalte) = '17.03'

Das sollte doch gehen?

[jobo]

Zitat von nahpets:

Oder will man hier dem Anwender nur die Eingabe von 5 weiteren Zeichen ersparen, also eine unsinnige Faulheit unterstützen?

Dann scheidet das von Jobo zu Sprache gebrachte Between leider aus.

Also man kann sich ja viele Szenarien denken, die Ursache für diese "verstümmelte" "Datums"eingabe sein könnten.
Naheliegend find ich hier, das Datum des aktuellen Jahres ist gemeint bzw. ist ja 2016 im EP explizit genannt. Ich gehe mal davon aus, der TE wird schon wissen was er sucht und kann meinen Beispielcode entsprechend abändern, wenn es dann doch ein anderes oder viele Jahre sein sollen.
Mir ging es wie geschrieben primär um die Frage, wie man grundsätzlich eine solche Aufgabe lösen kann ohne dass gleich Vergelwaltigung im Spiel ist.
Angenommen, es soll doch nach allen 17.3. Vorkommen in allen Jahren gesucht werden, ist mein Vorschlag "etwas umständlich", aber das könnten wir noch herausfinden, falls der TE sich jemals wieder meldet.