Was sind parametrisierte SQL-Statements und wann anwenden?

[Dejan Vu]

Zitat von mkinzler:

Zitat von joachimd:

.. sondern direkt mit AsString, AsDate usw arbeiten, damit der zu erwartende Datentyp auch schon im Code klar ist

Dann hat man u.U. aber viele unnötigen Cast-Operationen.

Den Einwand verstehe ich nicht. Man hat gerade keine Cast-Operationen, und damit auch keine Unnötigen.

Delphi-Quellcode:

myQuery.ParamByName('Foo').Value := a;
myQuery.ParamByName('Bar').Value := b;
// vs
myQuery.ParamByName('Foo').AsString := a;
myQuery.ParamByName('Bar').AsDateTime := b;

Bezüglich der Feldnamen/Tabellen als Parameter: Wenn ich mir meine WHERE-Klausel dynamisch zusammenbauen will, wäre das vielleicht ganz praktisch, aber da muss man eben direkt an die Query ran. So wild ist das ja nun auch nicht.

[TRomano]

Zitat:

von Dejan Vu
myQuery.ParamByName('Foo').Value := a;
myQuery.ParamByName('Bar').Value := b;
// vs
myQuery.ParamByName('Foo').AsString := a;
myQuery.ParamByName('Bar').AsDateTime := b;

In deinem Beispiel beschreibst Du genau das Problem: Deinen Feldnamen sind 'Foo' und 'Bar' und woher soll man wissen, was wirklich hinter den Feldnamen an Typen steckt. Sollte mal ein anderer Entwickler an deinen Source ran ... viel Glück !
Im zweiten Teil ist es klarer und verständlicher ...

[TRomano]

Und noch etwas fällt mir sehr oft auf: in großen Query-Loops wird gerne mit .FieldByName(..) oder ParamByName(..) gearbeitet. Den letzten "Rekord", den ich da sah waren ca. 30.000 Loops über 38 Felder jeweils mit .FieldByName(..) !!! Da kann man auch entweder über den DataSet-Editor persistente Felder anlegen oder eben Variablen nach dem Muster oFldName := DataSet.FieldByName('Name') anlegen. Erstens kann man Laufzeitzeiter-Fehler abfangen (if (oFldName = nil) und zweitens wird man mit einem nicht unerheblichen Performance-Plus belohnt ... oder optimiert der Delphi-Compiler so etwas weg

Gruß Thomas

[himitsu]

Zitat von TRomano:

Im zweiten Teil ist es klarer und verständlicher ...

Und der Compiler prüft auch die zugewiesenen Typen.

Ja, bei Schleifen, kommt man besser, wenn man sich die Felder vorher besorgt, falls das die Komponente nicht gleich bietet.
Einige Query-Komponenten (auf der Form abgelegt) bieten die Möglichkeiten die ensprechenden Feld-/Paramer-Komponenten (TField/TParam) direkt erstellen zu lassen.

Delphi-Quellcode:

Query.Insert;
QueryFeldA.AsString := '123';  // bzw. Query.FeldA.AsString := '123';
Query.Post;

statt

Delphi-Quellcode:

Query.Insert;
Query.FieldByName(FeldA).AsString := '123';
Query.Post;

Das gibt im Code nochmal einen Schritt mehr, in punkto Codesicherheit, da hier der Compiler die hingeschriebenen Komponentennamen prüfen kann, ob es das TField auch gibt
und die Codevervollständigung schlägt einem die Namen ebenfalls vor.

Entsprechendes gilt z.B. auch für die ORMs.





Nja, selbst wenn man nicht das Performance-Plus ausnutzt und wenn man oft im Code irgendwelche Queries aufruft, dann kann man dennoch nummerierte Parameter benutzen.

Delphi-Quellcode:

with x.LoadSql('SELECT * FROM tabelle WHERE feld = :param', ['abc']) do 
  try
    while not EoF do begin
      // mach was, mit FieldByName['xxx']
      Next;
    end;
  finally
    Free;
  end;

S := x.GetStr('SELECT xxx FROM tabelle WHERE feld = :param AND x <> :x', ['abc', 3]);
ShowMessage(S);

So ist der Code immernoch übersichtlicher und fehlerunanfälliger, als wenn da erst der SQL-String wirr zusammengemanscht wird.

Das Parameter-Array kann dabei z.B. die SQL-Parameter in der Reihenfolge der benutzen Namen enthalten, gefolgt von eventuellen Makros.

[Dejan Vu]

Zitat von TRomano:

Im zweiten Teil ist es klarer und verständlicher ...

Gerade *DAS* meinte ich ja!

[TRomano]

Okay. Dann hatte ich das zu schnell gelesen ... es geht halt stramm dem langen WE zu !