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:
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

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 von Daniel:

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 von Daniel:

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

s.o.

Zitat von Mavarik:

Ja schon... Habe jetzt
SQLQuery.ResourceOptions.PreprocessCmdText := false;
genommen...

[Mavarik]

Zitat von RWarnecke:

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" immer funktionieren...

Mavarik