FMX-FireDac "!" Fehler oder Feature?

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

[Mikkey]

Zitat von Mavarik:

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

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

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

Mavarik

Was ist natives Sql?

[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...