SQL über Memo und edit text

[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.