Problem mit Date in SQLite3 und Firedac

[Fritzew]

Hallo,
ich habe hier ein seltsames Problem
SQLLITE, Berlin U2 , Firedac

Ich bin daran ein altes Project (nicht von mir) von der BDE nach Firedac zu konvertieren jetzt steh ich echt auf dem Schlauch
Die Daten sind schon alle in einer neuen SQLite DB

Folgende Tabelle (gekürzt) :

Code:

CREATE TABLE "rechnungen"(
    "ID" INTEGER PRIMARY KEY,   
    "Zahlbis" DATE, 
    "Mahnstufe" INTEGER DEFAULT 0,
    "Gebucht" BOOLEAN DEFAULT false, 
    "istBezahlt" BOOLEAN DEFAULT false, 
    "istTeil" BOOLEAN DEFAULT false,    
    "Gesamtbetrag" CURRENCY, 
    "Zahlbetrag" CURRENCY
   );

Mit dieser Query:

Code:

SELECT
  SUM(Gesamtbetrag) as ZAHLUNG , Mahnstufe
FROM  RECHNUNGEN
WHERE (Gebucht and ((not istbezahlt) or istteil))
      and (
            coalesce (Gesamtbetrag, 0) > coalesce(Zahlbetrag, 0)
         /*   and ( ZAHLBIS <= :HEUTE ) */
         /*   and ( ZAHLBIS <= CURRENT_DATE ) */
     )

GROUP BY
  MAHNSTUFE
ORDER BY 
   MAHNSTUFE

Das funktioniert und liefert das gewünschte Ergebnis

Nehme ich eine der Zeilen mit dem ZAHLBIS in die Abfrage
kommen keine Ergebnisse mehr zurück

Das erste Feld wird zu einem BLOB???

Im SQLite expert funktioniert das ohne Probleme
Hat jemand ne Idee?

[jobo]

"kommt kein Ergebnis"
also leere Menge?
Oder vielleicht unterdrückter Fehler in Try Finally/Except?

Wenn Du die Tabelle mit dem Date Typ in Delphi persistierst, welcher Datentyp wird dann in Delphi angezeigt?
Und was bedeutet ".Nehme ich eine der Zeilen mit dem ZAHLBIS in die Abfrage .."
Als Where Bedingung? Oder nur zur Ausgabe?

Wenn als "Where", wie übergibst Du den Datentyp?

fYI: sqLite arbeitet intern nicht mit Datentypen, dazu gibt es hier auch schon Threads, die das bearbeiten. Bei sqLite selbst auf der HP ist das auch erläutert.

[p80286]

Zitat:

Zitat von Fritzew (Beitrag 1355374)

Nehme ich eine der Zeilen mit dem ZAHLBIS in die Abfrage

verstehe ich so, daß der Kommentar um

SQL-Code:

 /*   and ( ZAHLBIS <= :HEUTE ) */

gelöscht wird.
Da suche ich erst einmal nach den üblichen Verdächtigen
Was steht in :HEUTE ?
passt das Format/der Typ überhaupt zu ZAHLBIS?

Zitat:

Zitat von jobo (Beitrag 1355389)

fYI: sqLite arbeitet intern nicht mit Datentypen, dazu gibt es hier auch schon Threads, die das bearbeiten. Bei sqLite selbst auf der HP ist das auch erläutert.

Wenn ich so etwas lese, dann erinnert mich das an "Nagel mit Rohrzange in Wand schlagen".

Gruß
K-H

[Ghostwalker]

Jobo:

Gemeint sind die 2 auskommentierten Zeilen im SQL-Code :)

Bei der 2. Variante mit CURRENT_DATE stellt sich die Frage nach dem Type nicht, da es eine SQL-Funktion ist (die es auch in SQLite gibt).



@Fritzew:

Bei 1. Variante (mit :HEUTE) ist wirklich die Frage, was reingeht. Aber die CURRENT_DATE Variante sollte auf alle Fälle funktionieren.

[Fritzew]

Es ist tatsächlich so das mit dem CURRENT_DATE der Feldtyp

Code:

  SUM(Gesamtbetrag) as ZAHLUNG

als Blob zurückkommt als leere Menge

Wenn ich den Parameter benutze mit

Delphi-Quellcode:

opSum.Params[0].AsDate := Date;

Habe ich auch eine leere Menge und der Feldtyp ist ein Blob

Zitat:

Zitat von Ghostwalker (Beitrag 1355396)

Jobo:

Bei 1. Variante (mit :HEUTE) ist wirklich die Frage, was reingeht. Aber die CURRENT_DATE Variante sollte auf alle Fälle funktionieren.

Führe ich die folgende Abfrage SqlExpert aus funktioniert sie, mit Delphi nicht -> leere Menge

Code:

select Zahlbis from rechnungen
where Zahlbis not NULL
and zahlbis <= CURRENT_DATE
order by Zahlbis

Lasse ich den Vergleich mit CURRENT_DATE weg klappt es

[himitsu]

In der Connetion mal das SQL loggen?

Nicht dass FireDAC auf die geniale Idee kommt und CURRENT_DATE local ersetzt.

[DeddyH]

https://www.sqlite.org/datatype3.html

Zitat:

2.2. Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.

Nachdem ich das gelesen habe, bin ich dazu übergegangen, Datumswerte als TEXT abzuspeichern und die Konvertierung mittels Hilfsklasse zu implementieren.

[jobo]

Zitat:

Zitat von Ghostwalker (Beitrag 1355396)

Gemeint sind die 2 auskommentierten Zeilen im SQL-Code :)

Ja, ich hab zunächst nicht geschnallt, was mit (auskommentierte) Zeilen gemeint war.

[jobo]

Zitat:

Zitat von Fritzew (Beitrag 1355401)

Es ist tatsächlich so das mit dem CURRENT_DATE der Feldtyp

Code:

  SUM(Gesamtbetrag) as ZAHLUNG

als Blob zurückkommt als leere Menge

Ich benutze sqlite nicht auf diese Art, aber ich schätze das BLOB Problem ist ein Folgeeffekt, der sich bei der Rückgabe von Werte (Korrekte Behandlung des Datumsparameters) so nicht ergeben würde.
Ggf könnte man sqLite mal per Union Clause oder sum(gesamtsumme)+0 zu einem anderen Typen zwingen.

[Ghostwalker]

Ich persönlich speicher Datum und Zeitwerte generell als Unixtimestamp (integer). Lediglich für die Anzeige im Programm selbst wandel ich das mal um. Dafür bieten die Programmiersprachen, die ich kenne, alle in irgendeiner Form eine Konvertierung an (Bei Delphi UnixToTDateTime bzw. TDateTimeToUnix), sofern sie nicht selbst diesen Typ nutzen.