SQL-Statement doesn't return rows

[Khanysha]

Hallo zusammen,
ich verzweifle ein bisschen.
Ich beschäftige mich seit neuestem mit Datenbanken bzw deren Zugriff über ein Delphi-Projekt. Ich nutze hierfür SQLite und für den Zugriff UniDAC. Ich habe eine Tabelle mit dem SQLite-Browser erstellt. Via Grid und nem Memo kann ich die Tabelle anzeigen lassen und SQL-Befehle ausführen.

Nun zu meinem Problem:
wenn ich INSERT INTO Tabelle(Spalte1, Spalte2) VALUES ('Wert1','Wert2'); ausführe, bekomme ich die Fehlermeldung: SQL-Statement doesn't return rows führt die Anweisung aber dennoch aus. Wenn ich die Aussagen von Onkel Google richtig verstehe sagt die Fehlermeldung, dass es diese Zeile noch nicht gibt. Nun will ich ja mit INSERT INTO einen neuen Datensatz anlegen, natürlich ist der noch nicht da, deswegen nutze ich das doch?!

Verstehe ich da nun was falsch? Muss ja, sonst käme die Meldung ja nicht :oops:

LG

[Neutral General]

Du darfst die Query nicht mit "Open" ausführen, sonder mit "ExecSQL".
Mehr ist es nicht.

Alles was keine Datensätze zurückliefert geht über ExecSQL.

[mkinzler]

Bzw. wenn man sich nicht für die Rückgabe interessiert.

[Khanysha]

Danke für deine Antwort. Das war es wirklich. *Kopf-->Tisch*

[Khanysha]

Zitat:

Zitat von mkinzler (Beitrag 1348415)

Bzw. wenn man sich nicht für die Rückgabe interessiert.

Aktuell...sagen wir mal so ist es ein Spielprojekt um zu verstehen. Angefangen mit: Einfügen, Ändern und löschen (und das nicht über den Navigator :D) von Datensätzen und natürlich visualisieren. Es soll nachher in ein größeres Projekt gebastelt werden, aber dazu muss ich erst verstehen was ich da mache und wenn es Fehler gibt warum ich die habe :)

[mkinzler]

Bei ExecSQL wird die Abfrage ausgeführt, das Ergebnis aber nicht geholt. Das ist im Normalfall aber nicht sinnvoll.
Liefert die Abfrage ein Ergebnis -> Open, wenn nicht -> ExecSQL.

[Khanysha]

Zitat:

Zitat von mkinzler (Beitrag 1348426)

Bei ExecSQL wird die Abfrage ausgeführt, das Ergebnis aber nicht geholt. Das ist im Normalfall aber nicht sinnvoll.
Liefert die Abfrage ein Ergebnis -> Open, wenn nicht -> ExecSQL.

Also muss ich sogesehen beides verwenden? Wenn ich aber einen Datensatz frisch anlege, dann gibt es doch kein Ergebnis oder? Zu dem Zeitpunkt wo ich das ausführe gibt es ID x mit den WertenY und WertenZ ja noch nicht.

[Neutral General]

Machts nicht zu kompliziert.

SELECT --> Open
INSERT/UPDATE/DELETE/ALTER/CREATE/... --> ExecSQL

[himitsu]

Einfach gesagt: Was Datensätze zurückliefern "könnte" mit OPEN (egal, ob es "gerade" keine gibt)
und was niemals ein ResultSet liefert, das mit EXECUTE.

Oder, wie schon gesagt wurde, SELECT mit OPEN und Rest mit EXECUTE.




Aber wer es genauer wissen will, bezüglich dem SQL-Sprachumfang. :stupid:
Wann wird OPEN verwendet: (ansonsten EXECUTE)

Data Manipulation Language (DML) -> hier alle Abfragebefehle, sonst nicht
Data Definition Language (DDL) -> nie
Data Control Language (DCL) -> meistens nicht

Data Query Language (DQL) -> immer
Transaction Control Language (TCL) -> nie



EXECUTE geht immer und OPEN wirft einen Fehler, wenn das Query "niemals" ein ResultSet liefern würde.

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1348426)

Bei ExecSQL wird die Abfrage ausgeführt, das Ergebnis aber nicht geholt. Das ist im Normalfall aber nicht sinnvoll.

bei einem SELECT-Statement

Zitat:

Zitat von mkinzler (Beitrag 1348426)

Liefert die Abfrage ein Ergebnis -> Open, wenn nicht -> ExecSQL.

Gruß
K-H

[Khanysha]

Zitat:

Zitat von himitsu (Beitrag 1348435)

Einfach gesagt: Was Datensätze zurückliefern "könnte" mit OPEN (egal, ob es "gerade" keine gibt)
und was niemals ein ResultSet liefert, das mit EXECUTE.

Oder, wie schon gesagt wurde, SELECT mit OPEN und Rest mit EXECUTE.

Ich hab nun lange über der Aussage gesessen, ich bin mir nicht sicher ob ich das richtig verstehe.
Meine Anweisungen führe ich ausserhalb des Quellcodes aus. Habe ein Memo um meine Anweisung rein zu meißeln und kann dann per ButtonClick diese auch ausführen. Jetzt weiß ich aber nicht wie ich SELECT und den Rest trenne, da ich das ja ausserhalb mache? Ich öffne die Tabelle mit OPEN wenn ich den CennectButton klicke und wenn ich im Memo eine Anweisung habe mache ich das mit ExecSQL, nun kann ich aber auch ein SELECT im Memo stehen haben. Dann sollte er vermutlich nicht mehr mit ExecSQL arbeiten oder? Ich glaub meine Gedanken verknoten sich da gewaltig. Muss ich dann eine Abgrenzung reinbringen wie: Wenn Select dann das ansonsten das andere?

LG

[jobo]

Zitat:

Zitat von Khanysha (Beitrag 1348470)

Muss ich dann eine Abgrenzung reinbringen wie: Wenn Select dann das ansonsten das andere?

LG

Ja, wenn Du mit einem Memo arbeitest, bleibt Dir nichts anderes übrig.
Du kannst zu Anfang aber auch einfach trennen.
2 memos, eins mit Grid (Ausgabe) verknüpft und eines nur für Anweisungen ohen Datenausgabe (statt dessen vielleicht mit rows affected Prüfung / Ausgabe, aber das ist wieder ein neues Thema).
Ich schätze, Du hast als Anfänger sicher viele Baustellen. An der Stelle würde ich es mir vielleicht erstmal leicht machen.

[himitsu]

Man kann versuchen eine Query-Analyse zu machen und darüber entscheiden

oder einfach zwei Buttons (Open / Execute)

oder ganz billig Try-Except um das Open und NUR diese eine Exception abfangen ... da kann man auch das Grid disablen oder ein Label anzeigen, wenn "SQL-Statement doesn't return rows" aufgetreten ist.

[Khanysha]

Zitat:

Zitat von himitsu (Beitrag 1348482)

oder ganz billig Try-Except um das Open und NUR diese eine Exception abfangen ... da kann man auch das Grid disablen oder ein Label anzeigen, wenn "SQL-Statement doesn't return rows" aufgetreten ist.

Ist ganz billig auch korrekt? Ich will mir nicht gleich "Falsches" angewöhnen, wenn ich lerne dann (hoffentlich) gleich richtig :)

LG

[jobo]

Ja, wenn Du genau die eine Exception abfängst und behandelst ist es ok.

[himitsu]

Wenn an der Stelle Statements erlaubt sind, die kein ResultSet liefern, dann ist es OK.
Abfangen des einen "Fehlers" und ihn ordentlich behandeln ... für dich ist dieser "Fehler" dann halt kein Fehler, sondern nur eine "Information".
* nachher auswerten und diesen einen Fehler als "nicht schlimm" einstufen

Oder, wie gesagt, man kann das vorher entscheiden und dann Beides (SELECT oder nicht) getrennt behandeln
* 2 Knöpfe -> der Benutzer entscheidet
oder
* Query analysieren und versuchen rauszufinden ob OPEN oder EXECUTE nötig ist

[Neutral General]

Es ist sicher nicht 100% wasserdicht aber du hast bestimmt 80-90% aller Fälle abgedeckt wenn du einfach nur schaust ob das SQL mit "SELECT" beginnt.

[nahpets]

Also ich löse das Problem ganz einfach:

Sind die ersten 6 Zeichen des Statement = select, dann rufe ich open auf, ansonsten ExecSQL.

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]);

(Jetzt nur so hingedaddelt, nicht getestet.)

[haentschman]

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.

[Khanysha]

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.

Keine Sorge,es ist mein Testprojekt um zu lernen, damit ich es nachher in Programm richtig mache :) und ja ich lese mich morgen mal schlau wegen SQL Injection

Zitat:

Zitat von himitsu (Beitrag 1348488)

...
Abfangen des einen "Fehlers" und ihn ordentlich behandeln ... für dich ist dieser "Fehler" dann halt kein Fehler, sondern nur eine "Information".
* nachher auswerten und diesen einen Fehler als "nicht schlimm" einstufen

Oder, wie gesagt, man kann das vorher entscheiden und dann Beides (SELECT oder nicht) getrennt behandeln
* 2 Knöpfe -> der Benutzer entscheidet
oder
* Query analysieren und versuchen rauszufinden ob OPEN oder EXECUTE nötig ist

Ich werd einfach alle mal ausprobieren und schauen welches mir besser schmeckt :) Danke

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]);

(Jetzt nur so hingedaddelt, nicht getestet.)

Auch dieses werde ich testen :)


Danke für eure Antworten, ich schaue mir das morgen nochmal an und melde mich dann wieder. Für heute bin ich durch *schwitz*

LG

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

[jobo]

Zitat:

Zitat von Morphie (Beitrag 1348594)

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

Sie ist nicht immer richtig, das allerdings in ganz anderen Anwendungsfällen. Hier im Beispiel bei programmatischer Weiterverarbeitung, die sowieso nur auf gezielte Anwendungsfälle zutreffen kann und nicht bei der interaktiven Eingabe eines SQL Statements durch den Anwender.
Wir können ruhig die Kirche im Dorf lassen oder?

[Khanysha]

Zitat:

Zitat von jobo (Beitrag 1348597)

"select" ist nicht das gleiche wie

Code:

 Select ..

(voranstehendes Leerzeichen)

Code:

-- Kommentar: jetzt die Menge abfragen
select ..

Code:

select ..

Ich bin mir dessen bewusst das Select nicht select ist, aber deswegen doch AnsiLowerCase, das macht doch alle Buchstaben klein. Gut das mit dem Leerzeichen ist natürlich so ne Sache.

Ich mache mich mal dran die Exception abzufangen.

EDIT: Also mit der Exception hab ich noch so meine Probleme, hab ich aber jedesmal... Aber was die Leerzeichen anbelangt, kann ich doch mit TrimLeft arbeiten, dann kannst soviele Leerzeichen davor tackern und es interessiert keinen.

Edit2: Okay der Ausschnitt mit dem Kommentar könnte noch ein Problem werden. Nachher werden ja nur Daten aus der Datenbank abgefragt, um sie auswählen zu können und dann nachher noch zu Drucken. Man/Der Benutzer arbeitet gar nicht mit den SQL-Abfragen.

LG