Parameter unter Firedac

[DeddyH]

Aus der Hilfe:

Zitat:

function ExecSQL(const ASQL: String; const AParams: array of Variant; const ATypes: array of TFieldType): LongInt; overload; ...

Die vierte überladene Methode führt die in ASQL angegebene SQL-Anweisung oder die Anweisung, die der Eigenschaft SQL zugewiesen ist, aus, wenn ASQL leer ist. Sie gibt die Anzahl der aktualisierten Zeilen zurück. AParams repräsentiert ein offenes Array von Parameterwerten.
ATypes repräsentiert ein offenes Array von Parameterdatentypen, die der Abfrage zugewiesen werden.

Delphi-Quellcode:

FDQuery1.ExecSQL('insert into mytab (f1, f2) values (:f1, :f2)',
  [100, 'qweqwe'], [ftInteger, ftWideString]);

[Delbor]

Hi zusammen

Sorry, wenn ich erst jetzt antworte - ich bin im Moment sozusagen im "MultitaskModus". Im Schweizer Fernsehen läuft geradwe eine Sendung, in der Leute aus Stein im Kanton Appenzell Ferien in der Wohnung eines deutschen Ehepaars in Stein an der Nordsee machen und umgekehrt...
@Himitsu:
Unter der automatischen Parametererstellung wusste ich erstmal nicht, was ich darunter verstehen sollte. Die Variablen müssen ja auch so in der bekannten Form im SQL-String angegeben werden (xx).

Zitat:

Sooooooo unklar ist hier doch nicht, was passiert?

Die zitierten Zeilen brauchts ja auch nicht, wenn TFDResourceOptions.ParamCreate true ist. Aus:

Delphi-Quellcode:

SQLString := 'Insert Into Bildtabelle(Thumbnail) Values (:LThumbMemory)';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.Params.CreateParam(ftBlob, 'LThumbMemory', ptInput);
  FDQueryMain.Params[0].LoadFromStream(LThumbMemory, ftgraphic);
  FDQueryMain.ExecSQL(false);

würde, wenn ich das jetzt nicht gründlich missverstanden habe:

Delphi-Quellcode:

SQLString := 'Insert Into Bildtabelle(Thumbnail) Values (:LThumbMemory)';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.ExecSQL(false);

Da wird zwar die Variable übergeben. Aber allein aus diesen Zeilen geht nicht hervor, ob die auch wirklich parametrisiert werden.


Gruss
Delbor

[himitsu]

Es bedeutet ganz einfach, dass FireDAC nach Zuweisen des SQL-Strings nach Parametern sucht, welche als :ParamName deklariert sind und dann macht FireDAC das Params.CreateParam, für die gefundenen Parameter (nur halt Typlos, da es den DataTyp ja nicht kennt)

Delphi-Quellcode:

SQLString := 'Insert Into Bildtabelle(Thumbnail) Values (:LThumbMemory)';
FDQueryMain.Options.ParamCreate := False;  // oder irgendwie so
FDQueryMain.SQL.Text := SQLString;
FDQueryMain.Params.CreateParam(ftBlob, 'LThumbMemory', ptInput);
FDQueryMain.ParamByName('LThumbMemory').irgendwas...;  // oder FDQueryMain.Params[0].irgendwas...;
FDQueryMain.ExecSQL(false);

Delphi-Quellcode:

SQLString := 'Insert Into Bildtabelle(Thumbnail) Values (:LThumbMemory)';
FDQueryMain.Options.ParamCreate := True;  // oder irgendwie so
FDQueryMain.SQL.Text := SQLString;
//FDQueryMain.Params.CreateParam(ftBlob, 'LThumbMemory', ptInput); // das macht FireDAC für dich
FDQueryMain.ParamByName('LThumbMemory').irgendwas...;  // oder FDQueryMain.Params[0].irgendwas...;
FDQueryMain.ExecSQL(false);

[Delbor]

Hi himitsu

Vielen Dank! Das macht die Sache klarer! Ich dachte wirklich, der sucht das ':' und setzt den Parameter dann auch gleich ein!

Auffallend ist/finde ich, dass in allen Beispielen ParambyName verwendet wird und nicht der Feldindex, wobei sich Embarcadero da ja eindeutig ausspricht: treten zwei gleiche Parameternamen auf, wird der erste verwendet und der zweite fallengelassen. Dabei galt schon unter der altehrwürdigen BDE der Weg über die FeldIndexes als der Sicherere.

Gruss
Delbor

[himitsu]

Der Index geht zwar schneller, aber wenn du z.B. mal am SQL was veränderst, dann ändert sich auch der Index, aber über den Namen gibt es niemals Probleme und im Code siehst auch schneller wo auf was zugegriffen wird.

Man nimmt ja auch meistens FieldByName und nicht Fields, wenn man auf die Felder zugreift.

Fallen gelassen wird nichts.
Der Parser geht von vorne nach hinden durch den String und die Parameter werden in der Reihenfolge in die Liste eingetragen, wie sie gefunden werden.
Kommt ein Parameter mehrmals im String vor, dann steht natürlich nur der "erste" Fund an seiner Stelle in der Liste und die nachfolgenden Funde werden nicht nochmal angehängt, da der Parameter dann ja schon existiert.

SELECT :a, :b, :a, :c

Delphi-Quellcode:

Params[0] = ParamByName('a')
Params[1] = ParamByName('b')
Params[2] = ParamByName('c')

SELECT :c, :b, :a, :a

Delphi-Quellcode:

Params[2] = ParamByName('a')
Params[1] = ParamByName('b')
Params[0] = ParamByName('c')

[Delbor]

Hi zusammen
Zitat von Sir Rufo:

Zitat:

Die Parameter werden erzeugt in FireDAC.Phys.SQLPreprocessor.TFDPhysPreprocessor.E xecute

Zumindest wer mit Delphi XE8 arbeite, wird da nichts finden - es ist wohl nicht das erste Mal, dass sich in Firedac einniges ändert.
Ich häng hier einige jpegs an, die hoffentlich meine Suche etwas dokumentieren können.

Gruss
Delbor

PS: Da muss ich wohl ziemlich geschlafen haben:

Zitat:

C:\Program Files (x86)\Embarcadero\Studio\16.0\source\data\firedac\ stan\param nichts gefunden habe...

[Sir Rufo]

Diese Klasse/Unit ist auch in Seattle nicht dokumentiert.

Nimm doch einfach den Debugger und stepp durch den Code. Wenn dir das zu langweilig ist, dann suche die Parameter-Klasse und setze einen Breakpoint im Create . Wenn dann dort angehalten wird, gehst du einfach durch den Callstack durch und findest die Stellen, die das aufrufen.

So mache ich das wenigtens und das führt eigentlich immer zum Erfolg.