SQL-Statement doesn't return rows

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1348510)

Hallöle...:P

wenn ich höre "SQL Statements vom User eingeben zu lassen" kriege ich Pick... :zwinker: Wenn du das nur als dein Testprogramm zum üben benutzt, dann ist alles gut.

Der Knackpunkt ist: SQL Injection Da solltest du dich mal schlau machen was das ist. :zwinker:
Deshalb sollte man auch immer Parameter in den Statements verwenden.

Wenn ich das richtig verstanden habe, geht es um eine Oberfläche um SQL-Statements ab zu setzen. Das wäre dann gewollte Injection:wink:.

Das mit dem SELECT am Anfang ist nicht immer richtig (und ziemlich frustrierend wenn ein Programm für ein paar K€ das nicht weiß)

@Khanysha
Was hast du vor? Nicht das wir Dich mit irgendwelchen guten Ratschlägen in die Wüste schicken.

Gruß
K-H

[nahpets]

Zitat:

Zitat von p80286 (Beitrag 1348517)

Das wäre dann gewollte Injection:wink:.

Schöne Formulierung ;-)

Zitat:

Zitat von p80286 (Beitrag 1348517)

Das mit dem SELECT am Anfang ist nicht immer richtig (und ziemlich frustrierend wenn ein Programm für ein paar K€ das nicht weiß)

Naja, wenn ich mir zum Lernen eine Datenbankoberfläche schreibe, dann kann ich mir merken: "Wenn am Anfang "Select" steht, bekomme ich eine Ergebnismenge, sonst nicht." Da reicht so eine Unterscheidung vollkommen aus.

Zitat:

Zitat von p80286 (Beitrag 1348517)

@Khanysha
Was hast du vor? Nicht das wir Dich mit irgendwelchen guten Ratschlägen in die Wüste schicken.

Mein Eindruck ist, dass wir hier durch unsere Diskussion schon so einiges an Sand ausgestreut haben. Hoffentlich geht das nicht ins Auge ;-)

Und beim Lernen des Umganges mit Datenbanken und SQL würd' ich mir erstmal keinen Kopp um "SQL Injection" machen.

Wenn's irgendwann mal an professionelle Datenbanksoftware geht, die auf die Menschheit "losgelassen" werden soll, dann wird das ein Thema, aber nicht, wenn's um's Erlernen von Datenbankgrundlagen und deren Nutzung mit Delphi geht.
Das halt' ich für deutlich übertrieben!

[Khanysha]

Guten Morgen zusammen,
mit dem Sand kann ich umgehen *Sandburg bau*
Mein Vorhaben ist mit einer kleinen Datenbankanbindung den Umgang mit eben dieser zu lernen. Ich gebe meine SQL-Anweisungen selber ein um zu schauen ob das auch so tut wie es soll. Macht es das nicht geht es auf die Suche nach dem Fehler. Es ist ein Testprojekt, wo nur ich Zugriff drauf habe. Später, wenn ich dann mal "soweit" bin, soll das ganze in ein größeres Projekt gebaut werden. Da geht es später um eine Adressverwaltung und noch ein paar anderen Kleinigkeiten und nein es ist kein Adressbuch :D

Ich werde dennoch mal was über die SQL-Injection lesen, nicht sofort aber ich werde lesen. Nun schwinge ich mich an mein Projekt und probiere die verschiedenen Dinge aus :)

LG

[Khanysha]

Zitat:

Zitat von nahpets (Beitrag 1348509)

Als Beispiel:

Delphi-Quellcode:

qry.sql.text := memo.text;
if AnsiLowerCase(Copy(qry.sql.text,1,6)) = 'select' then begin
  qry.Open;
end else begin
  qry.ExceSQL;
end;
StatusBar.SimpleText := Format('Von der Abfrage waren %d Zeilen betroffen.',[qry.RowsAffected]);

Getestet und funktioniert :) Nun probiere ich die anderen Sachen aus

Zitat:

Zitat von p80286 (Beitrag 1348517)

Das mit dem SELECT am Anfang ist nicht immer richtig (und ziemlich frustrierend wenn ein Programm für ein paar K€ das nicht weiß)

Kannst du mir das genauer erklären? Es soll doch nur für SELECT OPEN genommen werden, hab ich am Anfang einer Anweisung nicht SELECT oder die anderen stehen? Also kann ich das auch verdrehen oder gar verschachteln?
LG

[mkinzler]

Verdrehen nicht aber verschachteln oder Klammern.

[Morphie]

Es gibt auch noch diverse andere SQL-Befehle, die dir Daten zurück liefern.
z.B. INSERT mit einer entsprechenden Returning-Clause: http://firebirdsql.org/refdocs/langr...sert-returning

Die Regel "wenn select dann open und sonst execsql" ist grundlegend falsch.

[mkinzler]

Füt seienn Zweck extra einen komplexen Parser zu Schreiben, wäre aber mit Atomraketen auf Ameisen geschossen.

[jobo]

Ich vermute p80286 findet es traurig, dass die Komponenten nicht "von allein" erkennen, welche Form (Datenabfrage oder Befehl) verwendet wird.

Die Interpretation mittels

Code:

AnsiLowerCase(Copy(qry.sql.text,1,6)) = 'select'

funktioniert natürlich, aber eben nur genau dann, wenn es genauso im String drin steht. Was nötig wäre, um es "wasserdicht" zu machen wäre ein parsind (Parser) für diesen String und das ist nicht unbedingt anfänger Stoff.
Nur mal als Idee:
"select" ist nicht das gleiche wie

Code:

 Select ..

(voranstehendes Leerzeichen)

Code:

-- Kommentar: jetzt die Menge abfragen
select ..

Code:

select ..

(voranstehende Leerzeile)
Ein Parser könnte man verwenden, um den SQL String zu analysieren und festzustellen, welche Form im SQL String steht und anhand dessen entscheiden, ob "OPEN" oder "EXECUTE" verwendet wird.

Wenn Du die Erkennung mittels "copy(1,6)" verwendest, wirst Du sicher bald mal darüber stolpern, wenn Du versehentlich ein Leerzeichen vor dem Select stehen hast oder sowas.

Aber mach Dich nicht verrückt deswegen. Softwareentwicklung ist nicht immer eine Frage von Richtig/Falsch. Häufig geht es um Aufwand und Nutzen. Der Grad der Umsetzung wird gelegentlich damit beschrieben, dass 10% Aufwand 90% Nutzen bringen, der restliche Aufwand (90%) für die letzen 10% Nutzen drauf geht. (So ungefähr, dazu gibt es glaube ich unter bestimmten Begriffen auch wissenschaftliche Untersuchungen)

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1348596)

Füt seienn Zweck extra einen komplexen Parser zu Schreiben, wäre aber mit Atomraketen auf Ameisen geschossen.

Genau! :)

[Morphie]

Das Fangen der Exception wäre aber eine zumutbare Option, finde ich.