SQL über Memo und edit text

[Tommi1966]

Hallo zusammen,
folgendes Problem beschäftigt mich
auf einer Form habe ich folgende Komponenten
Memo1,edit1,edit2,edit3,Button1

Wie kann man nun folgendes realisieren
memo1 wird zur Laufzeit rein geschrieben
edit1.text wird zur Laufzeit mit z.B. Test1 gefüllt
edit2.text, edit3.text ebenso

in dem Memo möchte ich nun folgendes eingeben ( die select soll Variable sein )

select * from Tabelle where (Feld1=edit1.text and Feld2=edit2.text and Feld3=edit3.text) or (Feld1=edit2.text)

wie muss ich in dem Memo die edit angeben, so das wenn ich auf den Button klicke folgendes erscheint

select * from Tabelle where (Feld1=Test1 and Feld2=Test2 and Feld3=Test3) or (Feld1=Test2)

Vorab schon mal vielen Dank für eure Mühe

[DeddyH]

Das Einfachste (wenn auch nicht das Eleganteste oder Performanteste) wäre wohl eine Stringersetzung mit StringReplace.

Delphi-Quellcode:

Memo1.Text := StringReplace(Memo1.Text, 'edit1.text', '' + Edit1.Text + '', [rfReplaceAll, rfIgnoreCase]);

[himitsu]

Zitat:

Das Einfachste

wären Parameter.

Delphi-Quellcode:

SQLKomponente.SQL.Text := 'select * from Tabelle where (Feld1=:edit1 and Feld2=:edit2 and Feld3=:edit3) or (Feld1=:edit2)';
SQLKomponente.ParamByName('edit1').Value := Edit1.Text;

Und wenn man das nicht nur ausführen, sondern wirklich den SQL-Text haben will,
dann gibt es bei so mancher Komponente oft auch eine Funktion, wo man sich den SQL-Text so zurückgeben lassen kann, dass dort die Makros und Parameter durch das Zugewiesene ersetzt wurden.

[Tommi1966]

Ich möchte euch danken

habe die Antwort von DeddyH in meinem Programm schon verarbeitet und es dient meinem Zweck voll und ganz

den Vorschlag von himitsu werde ich auch noch probieren

das Thema hätte sich so mit erledigt

der Programmiercode sieht nun so aus

text1:=query3.FieldByName('repmemo').AsString;
text1:=StringReplace(text1, 'edit8.text', '' + label25.Caption + '' , [rfReplaceAll, rfIgnoreCase]);
text1:=StringReplace(text1, 'edit9.text', '' + label26.caption + '' , [rfReplaceAll, rfIgnoreCase]);
text1:=StringReplace(text1, 'edit3.text', '' + Edit3.Text + '' , [rfReplaceAll, rfIgnoreCase]);
try
query1.active:=false;
query1.sql.clear;
query1.sql.add(text1);
query1.sql.text:=text1;
query1.active:=true;
except
on e: Exception do begin
MessageDLG('Fehler!'+#13#10+'Keine Auswahldaten vorgegeben !'+#13#10+e.message,mtError,[mbOk],0);
exit;

[himitsu]

Zitat:

Delphi-Quellcode:

'' + xxx + ''

Wer böse ist, der verwendet zumindest QuotedStr, auch wenn das eigentlich die Maskierung von Delphi-Stings ist und rein garnichts mit SQL zu tun hat, welches z.B. auch ein

Delphi-Quellcode:

\

kennt. (aber in unzähligen Deplhi-SQL-Tutorials wird das Verbrechen begangen diese Funktion zu verwenden, drum machen das zuviele)

Irgendwo in den Units der Query-Komponenten sollte sich aber eine Funktion verstecken, welche SQL-Namen und SQL-Strings richtig maskieren kann.
(meistens auch mit "Quote" oder "Escape" im Namen)


PS: [DELPHI]...[/DELPHI]

[Jumpy]

'' + label25.Caption + ''

Wieso funktioniert das? Hätte sowas erwartet:

'''' + label25.Caption + ''''

[p80286]

Mmm "'+irgendwas+'" wäre meine wahl.

Gruß
K-H

[Delphi.Narium]

Damit erhälst du dann aber einen String der '+irgendwas+' enthält ;-)

Will man in 'nem String ein Hochkomma haben, so muss man zwei Hochkommas schreiben.

Will man nun am Anfang eines Strings ein Hochkomma haben, muss man drei Hochkommas schreiben.

Soll ein String aus einem Hochkomma bestehen, muss man vier Hochkommas schreiben.

Meiner Meinung nach ist Jumpys Erwartung richtig.

[edit]
Wenn jedoch in label25.Caption und label26.Caption sowie Edit3.Text der Inhalt bereits in Hochkommata steht, dürfte es auch funktionieren.

In dem Falle wären jedoch das '' + bzw. das + '' entbehrlich.

[Medium]

Die Hochkommata (egal welche jetzt) wären jedoch falsch, wenn das entsprechende DB Feld kein Text wäre, und in dem Edit z.B. eine Zahl steht. Diese Unsicherheit allein würde mich schon dazu bewegen, das wie bereits vorgeschlagen mit Parametern zu machen.

[himitsu]

Zitat:

Zitat von Jumpy (Beitrag 1462223)

'' + label25.Caption + ''

Wieso funktioniert das? Hätte sowas erwartet:

'''' + label25.Caption + ''''

Stimmt.

Aber wie gesagt, Parameter oder zumindestens eine Escape-Funktion, die das richtig macht.

[Delphi.Narium]

Zitat:

Zitat von Medium (Beitrag 1462240)

Die Hochkommata (egal welche jetzt) wären jedoch falsch, wenn das entsprechende DB Feld kein Text wäre, und in dem Edit z.B. eine Zahl steht. Diese Unsicherheit allein würde mich schon dazu bewegen, das wie bereits vorgeschlagen mit Parametern zu machen.

Ja, schon.

Aber: Die meisten Datenbanken machen ja dann automatisch eine Typkonvertierung, so dass es meist halt doch schon geht. Schlimmstenfalls wird's durch die Typkonvertierung halt langsamer oder der eine oder andere Index kann nicht mehr genutzt werden.

Spaßig wird es, wenn der Text in Edit3.Text ein einzelnes Hochkomma enthält. Solche Fehler kann man dann wunderbar über Stunden hinweg suchen. (Vor allem dann, wenn man nicht gesagt bekommt, was denn da im Fehlerfalle so als Eingabe getätigt wurde ;-))

Solche Fehler suchen muss man aber nicht.

Die Leute, die die Parametrisierbarkeit erfunden haben, haben sich bestimmt was dabei gedacht (oder waren irgendwann die Fehlersucherei satt? ;-)).

Eigentlich spricht nichts gegen die Benutzung von Parametern. Alles andere führt früher oder später zu Problemen oder Sonderfällen, die man noch separat verarbeiten muss.

Und das Schöne an den Parametern ist: Wenn man die Datenbank wechselt ist das absolut tranzparent, man muss bei der Parameterbenutzung nix ändern. Bei allen anderen Vorgehensweisen wäre ich mir da nicht so sicher.

[p80286]

@Delphi Natrium
Ich hatte angenommen das als Ausgabe ....."Irgendwas".... heraus kommen sollte, darum das "'+irgendeinwert+'"
Abgesehen davon sind Parameter natürlich zu bevorzugen, wobei mann dann auch wenig mit irgendwelhen Hochkommata zu tun hat.

Gruß
K-H

[Medium]

Und nicht zu vergessen, vermutlich der Hauptgrund für Parameter: Kein SQL-Injection möglich. (Wird im hier gezeigten Fall wohl kaum kritisch sein, aber dennoch ein weiteres gutes Argument für Parameter.)

[p80286]

Leg ruhig einen Brikett auf. Der aktuelle Fall ist die Injektion schlechthin, da Du freie Hand hast irgendeinen SQL-Text einzugeben. Da hilft dann nur ein ordentliches Rechte-Management. Selbst ein Verstecken hinter Views ist da höchstens eine Erschwernis, aber kein Hindernis.

Gruß
K-H

[himitsu]

https://xkcd.com/327/

[p80286]

Ein

Code:

Drop table

ist doch so subtil wie ein Vorschlaghammer, Backup darüber nageln und gut ist. So etwas wie

SQL-Code:

delete from table where id mod 71=0

und das per Script alle 17 Tage, da kommt Freude auf. Die Daten sind Schrott aber es fällt nicht so schnell auf.:twisted:

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1462292)

SQL-Code:

delete from table where id mod 71=0

Das sind echte Gemeinheiten! Erzählst Du etwa aus Deinen alten Hackertagen? ;-)

Das wäre eine super Gelegenheit aus meiner SQL Zeit zu erzählen (vor der Erfindung von "Document Databases" , Micro Services, ..):
Wie nützlich war doch der Einsatz von Constraints! Sie verhinderten das Löschen von Datensätzen, die referentiell eingebunden sind. Dazu gehörte natürlich der Verzicht auf "Luxus" wie on-delete-cascade.(Dessen Einsatz meistens eher von Bequemlichkeit des Entwicklers zeugt)
Auch war es damals üblich, dem Normalverbraucher erst gar keine Löschrechte zu geben. Daten wurden eingegeben, korrigiert, als fehlerhaft markiert, stillgelegt, archiviert oder sonstwas, aber nicht gelöscht! Dazu braucht man dann folglich keine Löschrechte, geschweige denn "DROP" Rechte.

Ich will damit natürlich nicht sagen, dass man seitens des Client-Programms keine Schutzmaßnahmen wie etwa den Einsatz von Parametern ergreifen sollte, im Gegenteil, aber viele Schutzmaßnahmen gibt es auch für "die dumme Datenbank"! Sehr viele sogar!

[p80286]

Nö, ein Fehler der durch einen Programmfehler ausgelöst wurde (unerkannter wraparound). Und dann hab ich das ausgefeilt und einem Kollegen zum suchen gegeben.
Er war nicht amüsiert, vor allem weil das Schema nicht so leicht zu erkennen ist.

Gruß
K-H

[himitsu]

Joar, im selbstgebauten DMS hatten wir es auch, dass Dateien bei einem Kunden sporadisch verschwanden.
Hatte auch lange gedauert, bis ich den Fehler fand. Dort wurde was durch einen Trigger geändert, der RefeshAfterPost schnappte sich dadurch den falschen Datensatz und weitere Änderungen an der externen Datei gingen dann auf ein falsches Dokument los, was vor allem beim Löschen natürlich eher auffiel.

Nicht nur böse Benutzereinaben, sondern auch richtig falscher Programmcode kann viel Spaß machen.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1462401)

Nicht nur böse Benutzereinaben, sondern auch richtig falscher Programmcode kann viel Spaß machen.

Ehrlich, ich denke, das ist eine deutlich häufigere Ursache für Probleme, als missbräuchlicher Zugriff.
Man muss ja nicht paranoid reagieren, aber eine kritische Distanz zum eigenen Code (und dem irgendwelcher Libs) und die Anwendung bewährter Mechanismen kann eine Menge Schaden abwenden und auch Fehler direkt sichtbar machen.
In SQL habe ich z.B. immer schon eine gemeinsame Sequenz für die Primärschlüssel aller Tabellen verwendet. Das hat u.a. den Effekt, das fehlerhafte Updates oder Joins großteils ins Leere gehen, da nicht automatisch jede Zahl (irgend)einen Datensatz in der Tabelle trifft. Es verhindert Fehler nicht, aber findet sehr schnell Aufmerksamkeit, oft schon während der Entwicklung, spätestens in der Testphase.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1462410)

In SQL habe ich z.B. immer schon eine gemeinsame Sequenz für die Primärschlüssel aller Tabellen verwendet.

:thumb:
Wenn die Größe des Primärschlüssels zu knapp gewählt wurde, kann das natürlich auch daneben gehen.

Gruß
K-H

[jobo]

Klar, das muss man berechnen bzw. prognostizieren.

Ich will nicht ausschließen, dass man solche Dinge bei versehentlichem Erfolg anpassen muss. Aber die wenigsten der Millionen von IT Projekten erreichen Facebook Dimensionen, wo kritische Mengen für Schlüsselgrößen erreicht würden.