FireDac & SQLite: Lower() und Upper() nicht mehr unterstützt?

[Stewag]

Bei der Migration eines VCL Projektes von D11 auf D12 bekomme ich einen Laufzeitfehler beim Start:

Zitat:

EFDException mit der Meldung '[FireDAC][Phys]-327. Escape-Funktion [LOWER] wird nicht unterstützt'

Den Befehl benötige ich bei der Filterung einer FireDac Tabelle. Wenn ich die Filterbedingung heraus kommentiere, kommt kein Fehler.

Der Zugriff auf die SQLIte DB ist nicht encrypted.

Warum gehen diese Standardfunktionen unter D12 nicht mehr?

[Uwe Raabe]

Offiziell heißen die Funktionen LCASE und UCASE. Einen Unterschied zwischen D11 und D12 konnte ich erstmal nicht erkennen.

Kannst du ein kleines Beispiel zeigen, bei dem es unter D11 funktioniert, aber in D12 nicht?

[TurboMagic]

Zur Verschlüsselung: m.W. hat da SQLite jetzt etwas kostenpflichtig gemacht. Da war glaube ich was.

[himitsu]

Im OWER/UPPER im Dataset.Filter (Local SQL) oder im FilterSQL (WHERE) ?
Ersteres hat nichts mit der Datenbank zu tun.

und die Verschlüsselung:
https://www.delphipraxis.net/214094-...d-feature.html
https://www.delphipraxis.net/214322-...hluesseln.html

[Stewag]

Dieser Code läuft mit D11, aber nicht mit D12:

Code:

FDTable1.Filter := 'lower (Name) like ' + Quotedstr(lowercase(Filter.Text) + '%');
FDTable1.Filtered := true;

Encryption ist in FDConnection deaktiviert (enNo).

Syntax in SQLite: https://www.sqlitetutorial.net/sqlit.../sqlite-lower/
?

[himitsu]

Wie gesagt, das hat normalerweise nichts mit SQLite zu tun.

Es wird im Programm (vom Delphi) ausgewertet, nicht von der Datenbank und hat somit auch nichts mit deren Syntax zu tun. (bzw. ist immer meistens gleich, egal welche Datenbank verwendet wird)
Siehst du schon daran, dass die Grundfunktionalität bereits im TDataSet verbaut ist und z.B. auch beim TClientDataSet ohne eine Datenbank benutzt werden kann.

Zitat:

In einem Filter können natürlich auch komplexe Ausdrücke angegeben werden

OK, das ist mir neu.
https://docwiki.embarcadero.com/Libr...DataSet.Filter


z.B. beim pgDAC gibt es neben .Filter (lokaler Dataset.Filter) auch noch ein .FilterSQL (erweitert das WHERE vom SELECT).
Beim FireDAC scheint .Filter überschrieben zu sein und ... k.A. was es intern nutzt, aber ich würde eher auf LocalSQL tippen, anstatt auf was von der Datenbank.
http://docwiki.embarcadero.com/RADSt..._SQL_(FireDAC)



PS: Anstatt oder zusätzlich zum .Filter kann man auch "manuell" über .OnFilterRecord filtern.
https://docwiki.embarcadero.com/Libr...OnFilterRecord
OK, für ein einfaches Lower-/UpperCase vielleicht nicht unbedingt nötig.

[Stewag]

Danke Himitsu, aber ich kann dir nicht folgen.
Ich bin ja auch der Meinung, dass es mit Delphi und nicht SQLite zu tun hat.

pgDAC kenne ich nicht und .FilterSQL finde ich nicht.

Es ist doch nur ein simpler Filterausdruck, der bis D11 einwandfrei funktioniert hat.
Ich verwende ihn unter FilterChangeTracking.

[himitsu]

Es kann sein, dass Embarcadero die Syntax bei sich verändert hat. (im DataSet, bzw. im FireDAC)

Wie gesagt, normal hat das nichts mit SQLite oder sonsteinem verbundenem DBMS zu tun -> ganz eigene Syntax



Das, was TDataSet.Filter normalerweise kann, siehe TExprParser.GetFuncResultInfo bzw. TExprParser.TokenSymbolIsFunc in Data.DBCommon.pas
und eigentlich ist LOWER dort immernoch enthalten. :gruebel:
Aber wie gesagt/vermutet, ist .Filter im FireDAC-Query überschrieben und wird stattdessen eventuell LocalSQL nuzten. (das WHERE im SELECT erweitern wohl nicht, denn dann dürfte der Fehler anders klingen, wenn er aus dem DBMS käme)

Wie sieht dein Filter aus?

[Uwe Raabe]

Kann es sein, dass es nicht das lower ist sondern das lowercase?

[Stewag]

Zitat:

Kann es sein, dass es nicht das lower ist sondern das lowercase?

Nein. Lowercase() ist die Delphi Funktion, deren Rückgabe an die Filterbedingung unter Berücksichtigung des TEdit Filter.Text übergeben wird, lower() ist die SQL Syntax, die von SQLite verarbeitet wird:

Code:

FDTable1.Filter := 'lower (Name) like ' + Quotedstr(lowercase(Filter.Text) + '%');

Hat exakt so ja auch unter D11 noch funktioniert.

Im Anhang eine SQL Abfrage mit demselben Inhalt aus "DB Browser für SQLite", die direkt auf der Datenbank läuft.

[Stewag]

Zitat:

Wie sieht dein Filter aus?

na ja, hatte ich doch geschrieben:

Code:

FDTable1.Filter := 'lower (Name) like ' + Quotedstr(lowercase(Filter.Text) + '%');

Oder was meinst du?

[himitsu]

ahhh, vorhin irgendwie wieder übersehn

* Dachte grade erst das Escaping hinten bei % stimmt nicht, aber doch OK.
* Und wie isses ohne das Leerzeichen zwischen Lower und ( ?

[Stewag]

Zitat:

Und wie isses ohne das Leerzeichen zwischen Lower und ( ?

daran liegt es leider auch nicht.

[QuickAndDirty]

Geht das

Code:

FDTable1.Filter := Format(
  '''
  lower (Name) like '%0:s%%' 
  ''' ,
  [Filter.Text.ToLower]
  );

EDIT:

Code:

FDTable1.Filter := Format(
  '''
  LCASE(Name) like '%0:s%%' 
  ''' ,
  [Filter.Text.ToLower]
  );

TTable wandelt alles in einen Select statement um und aus deinem Filter wird

Code:

WHERE {LOWER(A.NAME)}

aus dem Filter wie Uwe Raabe ihn vorschlug wird

Code:

WHERE LCASE(A.NAME)

Hätte es nicht eigentlich umgekehrt sein müssen ? Weil LCASE das localsql makro ist?


Ich suche einen SQL Sanitizer... daher habe ich mir den preprocessor von Firedac mal angesehen ob der
missbraucht werden kann um mit parametern als sanitizer zu arbeiten bevor ich einen Unprepared SQL
abschicke mit evtl. zweifelhaftem Inhalt.

[Stewag]

...super QuickAndDirty, vielen Dank, läuft!

Eine Verbesserung ist allerdings noch nötig, da ich den Codeformatierer benutze. Dieser ändert die für die Anweisung nötige Syntax (Zeilenumbrüche & Leerzeichen).
Daher habe ich die Suchbedingung im Objektmanager einem TLabel zugewiesen. (lbFilter.Text: LCASE(Name)like '%0:s%%' or LCASE(Vorname)like '%0:s%%' or LCASE(Beschreibung)like '%0:s%%')

Damit fallen auch die vielen Hochkommata weg und aus der Filterbedingung wird einfach:

Code:

tBoote.Filter := Format(lbFilter.Text, [Filter.Text.ToLower]);

[haentschman]

Zitat:

einem TLabel zugewiesen

...warum einem TLabel und nicht einer Variable? :gruebel:

[Stewag]

Zitat:

...warum einem TLabel und nicht einer Variable?

weil die vielen Hochkommata den Aufbau der Variablen wieder ziemlich kompliziert machen würden.

[himitsu]

https://blogs.embarcadero.com/yukon-...ring-literals/

Aber ein weiterer Grund, warum die "neue" Syntax sch* ist, denn sie lässt sich nicht einzeilig nutzen, für sowas.



* in eine Ressourcendatei auslagern und von dort laden
* Außerdem gibt es Codeconverter, welche Test zu DelphiString und zurück umwandeln
* oder
* oder
* oder
Es gibt so viel, was besser ist, als ein Label die GUI zum Speichern.

[Stewag]

... mit einer Multiline String Konstanten habe ich es nicht geschafft.

Warum ist die Auslagerung in eine Ressourcendatei besser als ein unsichtbares TLabel?

[himitsu]

alles ist besser, als in der GUI :stupid:

[Uwe Raabe]

Zitat:

Zitat von Stewag (Beitrag 1533431)

... mit einer Multiline String Konstanten habe ich es nicht geschafft.

Delphi-Quellcode:

const
  cFilter = '''
  LCASE(Name)like '%0:s%%' or LCASE(Vorname)like '%0:s%%' or LCASE(Beschreibung)like '%0:s%%'
  ''';

:? Irgendwie sieht das hier im Forum nicht so aus wie in echt, deshalb noch ein Screenshot.

[himitsu]

[code] statt [delphi]

[delphi] lässt nur Leerzeichen am Zeilenanfang zu (und bei Ungerade vergisst es das Letzte), aber hier denkt er nach dem ''' geht die "Zeile" noch sehr viel weiter

[Uwe Raabe]

Offenbar kann der Formatter noch kein Delphi 12...

[Stewag]

Zitat:

const
cFilter = '''
LCASE(Name)like '%0:s%%' or LCASE(Vorname)like '%0:s%%' or LCASE(Beschreibung)like '%0:s%%'
''';

daraus macht der Codeformatter:

Code:

cFilter = '''
  LCASE(Name)like ' %0: s % % ' or LCASE(Vorname)like ' %0: s % % ' or LCASE(Beschreibung)like ' %0: s % % '
 ''';

Zitat:

Offenbar kann der Formatter noch kein Delphi 12...

... ja.

Ich bleibe erst mal bei der GUI.

[QuickAndDirty]

Ich nehme an der "Code Formatter" ist sowas wie ctrl+i in eclipse ???
Und in der Delphi IDE eingebaut?
Aber er funktioniert nicht mit den aktuellen MultilineStrings?
WTF.
Kann man mit compilerschaltern oder so regionen vom "Code Formatter" excludieren?
Gibt es Einstellungs Optionen?

Was ich schon festgestellt habe, ist dass

Code:

(*

in einem Multiline string die code block Erkennung der IDE komplett zerstören...
der String wird dann als bis zum ende der Datei gehend betrachtet...

[himitsu]

theoretisch wird (niemand sagt was aktuell ist und ob überhaupt oder ob nicht mehr) dran gearbeitet einen neuen CodeFormatter auf Basis des LSP zu bauen.

[Uwe Raabe]

Zitat:

Zitat von QuickAndDirty (Beitrag 1533439)

Ich nehme an der "Code Formatter" ist sowas wie ctrl+i in eclipse ???
Und in der Delphi IDE eingebaut?
Aber er funktioniert nicht mit den aktuellen MultilineStrings?
WTF.

Der Formatter sollte in D12 eigentlich gar nicht mehr enthalten sein, ist aber versteckt in der Modelling Option noch installierbar. Man muss den Formatter aber als deprecated betrachten, weshalb sich auch niemand um irgendwelche Bugreports dazu kümmern wird. Leider ist ein Ersatz noch unklar.

Zitat:

Zitat von QuickAndDirty (Beitrag 1533439)

Kann man mit compilerschaltern oder so regionen vom "Code Formatter" excludieren?
Gibt es Einstellungs Optionen?

Leider nein. Man kann allerdings das Formatieren auf den markierten Bereich einschränken (das mache ich zumindest schon eine Weile so).

Zitat:

Zitat von himitsu (Beitrag 1533440)

theoretisch wird (niemand sagt was aktuell ist und ob überhaupt oder ob nicht mehr) dran gearbeitet einen neuen CodeFormatter auf Basis des LSP zu bauen.

Mir ist davon zumindest nichts bekannt.

[dummzeuch]

Zitat:

Zitat von QuickAndDirty (Beitrag 1533439)

Ich nehme an der "Code Formatter" ist sowas wie ctrl+i in eclipse ???
Und in der Delphi IDE eingebaut?
Aber er funktioniert nicht mit den aktuellen MultilineStrings?
WTF.
Kann man mit compilerschaltern oder so regionen vom "Code Formatter" excludieren?
Gibt es Einstellungs Optionen?

Der eingebaute Code Formatter kann das tatsächlich nicht (deshalb ist er auch "deprecaded" und wird deshalb bei Delphi 12 normalerweise nicht automatisch mitinstalliert) und hat auch so seine Problemchen bei anderen ungewöhnlicheren Syntax-Konstruktionen.
Und nein, man kann auch keine Bereiche davon ausschließen, ein Feature, das schon länger gewünscht wird. Es gibt zwar Einstellungen (unter Tools -> Options), aber nichts, was bei diesem Problem hilft.

Der Code Formatter von GExperts kann Multiline Strings, allerdings noch nicht im bisher letzten (Alpha-)Release für Delphi 12. Er kann auch Code-Bereiche von der Formatierung ausnehmen bzw. nur die markierten Zeilen formatieren. Da Du aber vermutlich keine Lust hast, ihn Dir aus dem Sourcecode selbst zu compilieren, ist auch das keine Lösung, zumal es da immer noch bzw. schon wieder Probleme bei der Darstellung in High DPI gibt. Sorry, ich finde einfach keine Zeit, die ganzen neuen Fehler zu fixen.