MSSQL Datenbank, Select geht nicht

[p80286]

Zitat von mkinzler:

Noch besser wäre es (SQL-)Paramter zu verwenden.

Das wurde bisher so oft geschrieben, und wird immer noch ignoriert....

Gruß
K-H

[Jasocul]

Zitat von p80286:

Zitat von mkinzler:

Noch besser wäre es (SQL-)Paramter zu verwenden.

Das wurde bisher so oft geschrieben, und wird immer noch ignoriert....

Deswegen schreibe ich es nicht mehr. Lohnt offensichtlich den Aufwand nicht.

[hoika]

Hallo,
doch lohnt sich immer, es wachsen ja immer neue Programmierer nach, die das halt noch nicht wissen.
Aber wenn man hier mit falschen (nicht so ganz schönem) Beispiel (QuotedStr) vorangeht,
sollte man sich nicht wundern, dass es andere falsch machen.

Delphi-Quellcode:

qryproducts.SQL.Add(' WHERE kd_data.kd_vname like :SinnvollerParameterName');
qryproducts.ParamByName('SinnvollerParameterName').AsString:= edit1.text;

Ich glaube, im Informatik-Unterricht hatte ich das mit dem Parameter (Stichwort SQL-Injection) nicht.
Da war der Lehrer schon froh, wenn wir das Select und das Where richtig geschrieben hatten

[Jasocul]

Hast ja Recht.
Also dann zur Vollständigkeit. So sollte das eigentlich ein besseres SQL-Statement sein:

Delphi-Quellcode:

procedure TfrmGettingStarted.Button1Click(Sender: TObject);
 begin
  if dbMain.Connected then
  begin
    qryproducts.FetchOptions.AutoClose := False;
    qryproducts.SQL.Clear;
    qryproducts.SQL.Add('SELECT *');
    qryproducts.SQL.Add('FROM kd_data')           ;
    qryproducts.SQL.Add(' WHERE kd_data.kd_vname like :Vorname');
    qryproducts.SQL.ParamByName('Vorname').AsString := Edit1.Text;
    qryproducts.Open; // [Orders] table rows are accessable here
   end;
 end;

Vorteile:
1. Gefahr von Code-Injection verringert
2. Firlefanz mit QuotedStr oder wildem Anführungszeichengewedel entfällt
3. Bessere Lesbarkeit (siehe dazu Punkt 2)
4. Das Prepare funktioniert besser
Nachteile:
In sehr seltenen Fällen muss man den Type des Parameters noch definieren, weil die automatische Umsetzung des Parameters in den richtigen Typ nicht funktioniert. Das passiert nur sehr selten und wirkt sich selbst dann nicht immer aus. Hatte ich in den letzten 5 Jahren nur einmal.

Außerdem gleich mal das Exit rausgeschmissen.

[DasWolf]

Kleine Änderung dazu noch:

Delphi-Quellcode:

 procedure TfrmGettingStarted.Button1Click(Sender: TObject);
 begin
   if dbMain.Connected then
   begin
     if qryproducts.Active then
       qryproducts.Close;  //bei FireDac geht auch qryproducts.Disconnect();
     qryproducts.FetchOptions.AutoClose := False;
  
     qryproducts.SQL.Clear;
     qryproducts.SQL.Add('SELECT *');
     qryproducts.SQL.Add('FROM kd_data') ;
     qryproducts.SQL.Add(' WHERE kd_data.kd_vname like :kd_vname');
     qryproducts.SQL.ParamByName('kd_vname').AsString := Edit1.Text;
     qryproducts.Open;
   end;
 end;

Grundsätzlich sollten Eigenschaftsänderungen bei aktiven Queries vermieden werden (Siehe qryproducts.FetchOptions.AutoClose).
Parameterbezeichnungen wenn möglich so benennen wie das Feld (kd_vname).

Ich gebe bei Verwendung von Parametern immer den Datentyp mit an, weil bei mir immer ein Fehler auftritt:

Delphi-Quellcode:

qryproducts.SQL.ParamByName('kd_vname').DataType := ftString;
qryproducts.SQL.ParamByName('kd_vname').Value := Edit1.Text;

[TigerLilly]

Ein kleiner Hinweis:

Ein SELECT führt unter MSSQL immer zu kurzeitigen Locks während des Lesens, je nach concurrency und Datenmenge kann das von einem row lock über page lock zu einem table lock führen + so zu einem Deadlock, bei dem dann alles steht. Das lässt sich durch den Zusatz WITH (NOLOCK) unterbinden, was den Abruf auch beschleunigt. Der Preis, den man zahlt, ist, dass Änderungen anderer (DIRTY READ bzw READ UNCOMMIED) uU in das Select einfließen können, was egal, gewünscht oder auch unerwünscht sein kann.

Hintergundinfo dazu:
https://sqlperformance.com/2014/07/t...olation-levels

Und das ist für jeden, der mit MSSQL zu tun hat auch gut:
https://blogs.sentryone.com/aaronber...abits-revival/

[hoika]

Hallo,
ich mag Firebird, da ist das nicht so