FMX-FireDac "!" Fehler oder Feature?

[Mavarik]

Hallo Zusammen!

Ich habe meine SQLite Datenbank (Win/iOS/Andorid) auf FireDac umgestellt.

Jetzt kann ich keinen SQL Insert mehr mit einen "!" im Text machen.

Beispiel:

Delphi-Quellcode:

Felder := 'Del,Zahl1,Zahl2,Txt1,Txt2';
Values := '2,3,"Cool","Echt Doof!";

SQLQuery.SQL.Text := 'INSERT INTO '+FTableName+' ('+Felder+') VALUES (0,'+Values+');';

Ohne Firedac alles Prima, aber FireDac interpretiert das "!" daher bekomme ich die Fehlermeldung das es zu wenige Values angegeben sind.

Sollten nicht zwischen " belibige Texte angegeben werden können? oder Muss ich ' nehmen?
Oder wirklich aus jedem "!" ein "\!" machen?

Grüsse Mavarik

PS.:
Mit:

Delphi-Quellcode:

Values := StringReplace(Values,'!','\!',[rfreplaceall]);

Läuft die Routine zwar durch aber in der Datenbank steht dann auch '\!'...

[Daniel]

Das ist kein Fehler in FireDAC. Eigentlich ist Deine Herangehensweise nicht ganz sauber - die Query zu parametrisieren, wäre eigentlich besser und würde das o.g. Problem sofort lösen. Alternativ kannst Du auch die Eigenschaft "ResourceOptions.MacroExpand" auf "false" setzen.

Ich zitiere aus der Doku:

Use MacroExpand property to control macros expansion. If it is True, then their values will be substituted into SQL command text instead of corresponding macro markers. If it is False, then FireDAC does not substitute macro values into command text. The default value is True.
Setting MacroExpand to False, may be usefull if:
• target DBMS uses '!', '&' symbols in its own SQL dialect and FireDAC cannot recognize them as a SQL construction. Then SQL commands with these symbols may confuse FireDAC SQL preprocessor. See Preprocessing Command Text (  see page 56) for macros description.
• application does not use macros at all.
Setting PreprocessCmdText (  see page 878) to False, sets MacroExpand to False.

[Mavarik]

Ja schon... Habe jetzt

Delphi-Quellcode:

SQLQuery.ResourceOptions.PreprocessCmdText := false;

genommen...

Stellen Sie für MySQL dem Sonderzeichen dieses Zeichen "\" voran (z. B. "\"").

OK gilt nur für MySQL...

PS.:

Zitat:

Zitat von Daniel (Beitrag 1262589)

Eigentlich ist Deine Herangehensweise nicht ganz sauber

Bitte... Warum nicht... Native SQL Kommandos müssen doch gehen und sind "sauber".

Ich lade die Werte aus einer Textdatei warum soll ich das ganze dann noch umformen?

[Daniel]

"Sauber" war als Formulierung nicht präzise. Okay.
Wenn Du Parameter verwendest, musst Du Dich um den ganzen Kram wie die Escape-Zeichen nicht mehr kümmern und kannst Dich voll und ganz auf die eigentlichen Werte konzentrieren. Darin sehen viele Entwickler einen Vorteil von Parametern - aber es ist müßig.

[Daniel]

Viel wichtiger: Hat es denn Dein Problem gelöst?

[mkinzler]

Wenn man verstanden hat was SQL-Parameter sind, fragt man nicht mehr warum man sie einsetzen soll, sondern verwendet diese!

[DeddyH]

Zumal das ja (gefühlt) einmal die Woche angesprochen wird ;)

[RWarnecke]

Hallo Frank,

ich habe das auch zumAnfang so gemacht wie Du. Habe mit QuotedStr u.s.w gearbeitet. Aber seit ich die parameterisieren SQL-Abfragen einsetze, hatte ich solche Probleme nicht mehr. Zumal die prameterisierten SQL Anweisungen noch einen Vorteil haben, wenn Du die gleiche SQL-Anweisung nur mit unterschiedlichen Werten zum Beispiel in einer Schleife ausführst. es gibt sicherlich noch mehr Punkte.

Deshalb mein Rat, egal wie die Daten bei Dir ankommen, setze die Daten immer in parameterisierte SQL-Anweisungen um und die sparst Dir ein paar graue Haare mehr. ;-)

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1262594)

Viel wichtiger: Hat es denn Dein Problem gelöst?

s.o.

Zitat:

Zitat von Mavarik (Beitrag 1262591)

Ja schon... Habe jetzt

Delphi-Quellcode:

SQLQuery.ResourceOptions.PreprocessCmdText := false;

genommen...

[Mavarik]

Zitat:

Zitat von RWarnecke (Beitrag 1262599)

Deshalb mein Rat, egal wie die Daten bei Dir ankommen, setze die Daten immer in parameterisierte SQL-Anweisungen um und die sparst Dir ein paar graue Haare mehr. ;-)

Gerade auf IOS & Android geht es um Performance... Müssen die Parameter nicht alle wieder als ein SQL String zusammengebastelt werden damit dieser an den Treiber übergeben werden kann?

Außerdem sehe ich da keinen Vorteil...
Natives SQL "sollte" :stupid: immer funktionieren...

Mavarik

[Mikkey]

Zitat:

Zitat von Mavarik (Beitrag 1262601)

Gerade auf IOS & Android geht es um Performance... Müssen die Parameter nicht alle wieder als ein SQL String zusammengebastelt werden damit dieser an den Treiber übergeben werden kann?

Nö, das ist ja gerade der Sinn, dass die Werte nicht aus dem SQL-String herausgeholt werden müssen.

Zitat:

Zitat von Mavarik (Beitrag 1262601)

Außerdem sehe ich da keinen Vorteil...

Naja, dieses(!) Problem hättest Du nicht gehabt

[Daniel]

Stichwort "Performance": Solltest Du gleich eine größere Anzahl an Werten haben, dann könntest Du die "Batch-Funktionalität"-FireDAC nutzen. Grob gesagt übergibst Du der FireDAC-Komponente ein mehrdimensionales Array an Werten und lässt sie dann machen. Gegenüber einzelnen Requests konnte ich da Performance-Steigerungen um den Faktor 10 (!) erzielen.

Details dazu unter:
http://docwiki.embarcadero.com/RADSt..._DML_(FireDAC).

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1262601)

Gerade auf IOS & Android geht es um Performance... Müssen die Parameter nicht alle wieder als ein SQL String zusammengebastelt werden damit dieser an den Treiber übergeben werden kann?

Der Treiber muss gar nix zusammenbauen sondetn übergibt das parametrisierte Statement an die Db welche sich dann leichter tut das Statement abzuarbeiten. Nicht umsonst sind prepared Statement schneller als statements die ohne parameter arbeiten.

Zitat:

Außerdem sehe ich da keinen Vorteil...
Natives SQL "sollte" :stupid: immer funktionieren...

Mavarik

Was ist natives Sql?

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1262605)

Stichwort "Performance": Solltest Du gleich eine größere Anzahl an Werten haben, dann könntest Du die "Batch-Funktionalität"-FireDAC nutzen. Grob gesagt übergibst Du der FireDAC-Komponente ein mehrdimensionales Array an Werten und lässt sie dann machen. Gegenüber einzelnen Requests konnte ich da Performance-Steigerungen um den Faktor 10 (!) erzielen.

Details dazu unter:
http://docwiki.embarcadero.com/RADSt..._DML_(FireDAC).

Ja eben...

unter SQLite werden Parameter von FireDac nur emuliert.
und um aus einem String mit

Delphi-Quellcode:

SQL.Text := 'insert into Customers (ID, RegionID, Name, Note) values (:ID, :RegionID, :Name, :Note)';

wieder eine SQL Anweisung zu machen muss Firedac den String wieder zusammen bauen...
Weil die SQLite.dll nur SQL-Strings verarbeiten kann.

Übrigens ein

Delphi-Quellcode:

    SQLQuery.SQL.Text := 'BEGIN;';
    ...// inset 10000 Datensätze
    SQLQuery.SQL.Text := 'COMMIT;';

Hat zur Folge das erst alles in RAM kopiert wird und dann gebündelt an die DLL übergeben wird.

[mquadrat]

String-Operationen sind im Vergleich zu den ganzen grafischen Sachen und Animationen doch nicht wirklich teuer. Ich bezweifel, dass man da tatsächlich einen Geschwindigkeitsunterschied auf Android/iOS sieht. Wir verwenden in unserem Web-Framework auch RegExen und alle möglichen anderen String-Operationen (bei jedem Request) und erzielen trotzdem Geschwindigkeiten bei denen eine solche Pseudo-Optimierung schlicht nicht nötig ist.

Die meisten Projekte verwenden ja inzwischen ORMs und da wird IMHO auch immer mit Parametern gearbeitet. Noch dazu ist der ORM an sich ja noch mal eine Ebene der Indirektion, die Ressourcen benötigt.

Wir selber schreiben inzwischen nicht mal mehr die Queries, sondern nutzen einen Query-Builder mit Fluent-Interface, der ganz am Ende erst das parameterisierte Statement zusammenbaut.

[Daniel]

Frank, mach es so, wie Du Dich damit am besten fühlst.

Aber zwei Sachen kann man nicht stehen lassen, weil sie schlichtweg falsch sind:

Zitat:

Zitat von Mavarik (Beitrag 1262661)

unter SQLite werden Parameter von FireDac nur emuliert

Nein, weder einfache Parameter noch Array-Parameter werden emuliert. Einfache Parameter gehen immer und Array-Parameter gehen, wenn Du die Komponente entsprechend konfigurierst, indem Du die Eigenschaft "Params.BindMode" auf den Wert "pbByName" setzt. Seit iOS 6 (!) kommt SQLite in Version 3.7.13 daher und erfüllt damit die Voraussetzung für eine native Unterstützung von Array-Parametern.

Zitat:

Zitat von Mavarik (Beitrag 1262661)

Weil die SQLite.dll nur SQL-Strings verarbeiten kann

Ich bin durchaus froh, dass dem nicht so ist, denn sonst gäbe es ... sagen wir ... gewisse Probleme ... mit BLOB-Feldern.


Ich denke, es ist klar geworden, dass Du diesen Weg nicht gehen möchtest und das ist Dein gutes Recht.