SQL: select * from ... = "integer-wert"

[markon]

@ r_kerber: danke dir, dein vorschlag...

Delphi-Quellcode:

adoquery1.sql.Add ('select * from tabelle1 where TorDiff = ' + such;

...brachte folgende fehlermeldung: "Inkompatible Typen: String und Integer"
...dann hab ich die zeile folgendermasen´geändert:

Delphi-Quellcode:

adoquery1.sql.Add ('select * from tabelle1 where TorDiff = ' + inttostr(such));

... und siehe da, es funzt!! :thuimb:

[r_kerber]

Uuups. :oops:

Man sollte lesen was da steht.

Delphi-Quellcode:

adoquery1.sql.Add ('select * from tabelle1 where TorDiff = ' + ed_such.text);

So wäre es richtig gewesen.

[markon]

jo, stimmt!

Delphi-Quellcode:

adoquery1.sql.Add ('select * from tabelle1 where tordiff = ' + inttostr(such));

ist letztlich doppelt gemoppelt, erst den string in integer und dann wieder zurückwndeln.

Delphi-Quellcode:

adoquery1.sql.Add ('select * from tabelle1 where tordiff = ' + ed_such.text)

einfach das edit-feld angeben. fertig.
danke für deine hilfe
:cheers:

[Wormid]

Ich würde aber immer davon abraten, Benutzereingaben ungeprüft in SQL-Statements einzubauen.
Ich weiss jetzt nicht, ob Deine DB und die ADO-Schnittstelle mehrere Statements in einer SQL-Anweisung akzeptieren, aber wenn ja, dann hättest Du ein ziemliches Problem, wenn der User in das Edit ed_such folgenden Text eingibt:

Code:

1; drop table 'tabelle1';

Das setzt natürlich voraus, das der User gewillt ist, die Datenbank zu zerschiessen. Aber sowas soll ja leider mal vorkommen... :?

Gruß

Wormid

[r_kerber]

Zitat:

Zitat von markon

ist letztlich doppelt gemoppelt, erst den string in integer und dann wieder zurückwndeln.

Aber Du hast wenigstens vorher überprüft, ob in dem TEdit eine gültige Integerzahl eingegeben wurde.

[Garby]

Hallo, ich klink mich auch wieder ein :-D
Generell würde ich jedem abraten eine SQL-Anweisung ohne Parameter zu verwenden. Bei Access Datenbanken mag das ja keine Auswirkungen haben, aber hat man einen SQL Server dann muss eine Anweisung dieser Art

SQL-Code:

adoquery1.sql.Add ('select * from tabelle1 where tordiff = ' + ed_such.text)

vom Server jedesmal beim Ausführen neu geparst, und der jeweilige Ausfürungsplan neu erstellt werden.
Hat man hier eine Multiuserumgebung (z.Bsp. einen Internetserver) wird diese Datenbank früher oder später den Geist aufgeben.
Werden stattdessen Parameter verwendet kann sich der Server auf die zuletzt geparste Anweisung verlassen und braucht nur noch die Parameterwerte auszutauschen.
Bsp.:

Delphi-Quellcode:

procedure Tfrm_spiele.bt_suchClick(Sender: TObject);
var such :integer;
begin
adoquery1.Close;
adoquery1.sql.Clear;

such := strtoint(ed_such.text);

adoquery1.sql.Text := 'select * from tabelle1 where TorDiff = :such';
adoquery1.Parameters.ParamByName('such').Value := such;

adoquery1.Open;

end;

Auch wenn man keinen Datenbankserver zur Verfügung hat würde ich trotzdem vorschlagen gleich auf diese Technik zu setzten, weil die Anwendung auch besser skalierbar wird.

[r_kerber]

Hallo Garby,

ich kann mich dem nur anschließen. Ich wollte allerdings eine einfache Lösung anbieten. Dann sollte man auch darüber nachdenken, ob man diese Abfrage dann nicht fest in die ADOQuery einträgt und für jede Tabelle ein eigenes ADOQuery-Objekt nutzt.

Gruß in's schöne Tirol, wo ich immer wieder gern Urlaub mache. :bounce1: :bouncing4:

[Garby]

Das würde der Übersichtlichkeit des Projekts sicher guttun. Ausserdem hat man dann auch den Vorteil alle Parameter und zugehörigen Einstellungen bequem im OI zu tätigen.

Aber genug davon, ich glaub wir sollten an dieser Stelle keinen Datenbank-Crashkurs veranstalten :warn:

[markon]

@ garby

danke für dein posting. :thuimb: ist gut zu wissen was man besser machen kann. bei sehr vielen zugriffen lohnt sich das schon.