![]() |
Datenbank: SQLite • Version: 3.9.2 • Zugriff über: UniDAC
SQL-Statement doesn't return rows
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 |
AW: SQL-Statement doesn't return rows
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. |
AW: SQL-Statement doesn't return rows
Bzw. wenn man sich nicht für die Rückgabe interessiert.
|
AW: SQL-Statement doesn't return rows
Danke für deine Antwort. Das war es wirklich. *Kopf-->Tisch*
|
AW: SQL-Statement doesn't return rows
Zitat:
|
AW: SQL-Statement doesn't return rows
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. |
AW: SQL-Statement doesn't return rows
Zitat:
|
AW: SQL-Statement doesn't return rows
Machts nicht zu kompliziert.
SELECT --> Open INSERT/UPDATE/DELETE/ALTER/CREATE/... --> ExecSQL |
AW: SQL-Statement doesn't return rows
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. |
AW: SQL-Statement doesn't return rows
Zitat:
Zitat:
K-H |
AW: SQL-Statement doesn't return rows
Zitat:
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 |
AW: SQL-Statement doesn't return rows
Zitat:
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. |
AW: SQL-Statement doesn't return rows
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. |
AW: SQL-Statement doesn't return rows
Zitat:
LG |
AW: SQL-Statement doesn't return rows
Ja, wenn Du genau die eine Exception abfängst und behandelst ist es ok.
|
AW: SQL-Statement doesn't return rows
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 |
AW: SQL-Statement doesn't return rows
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.
|
AW: SQL-Statement doesn't return rows
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:
(Jetzt nur so hingedaddelt, nicht getestet.)
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]); |
AW: SQL-Statement doesn't return rows
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. |
AW: SQL-Statement doesn't return rows
Zitat:
Zitat:
Ich werd einfach alle mal ausprobieren und schauen welches mir besser schmeckt :) Danke Zitat:
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 |
AW: SQL-Statement doesn't return rows
Zitat:
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 |
AW: SQL-Statement doesn't return rows
Zitat:
Zitat:
Zitat:
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! |
AW: SQL-Statement doesn't return rows
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 |
AW: SQL-Statement doesn't return rows
Zitat:
Zitat:
LG |
AW: SQL-Statement doesn't return rows
Verdrehen nicht aber verschachteln oder Klammern.
|
AW: SQL-Statement doesn't return rows
Es gibt auch noch diverse andere SQL-Befehle, die dir Daten zurück liefern.
z.B. INSERT mit einer entsprechenden Returning-Clause: ![]() Die Regel "wenn select dann open und sonst execsql" ist grundlegend falsch. |
AW: SQL-Statement doesn't return rows
Füt seienn Zweck extra einen komplexen Parser zu Schreiben, wäre aber mit Atomraketen auf Ameisen geschossen.
|
AW: SQL-Statement doesn't return rows
Ich vermute p80286 findet es traurig, dass die Komponenten nicht "von allein" erkennen, welche Form (Datenabfrage oder Befehl) verwendet wird.
Die Interpretation mittels
Code:
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.
AnsiLowerCase(Copy(qry.sql.text,1,6)) = 'select'
Nur mal als Idee: "select" ist nicht das gleiche wie
Code:
(voranstehendes Leerzeichen)
Select ..
Code:
-- Kommentar: jetzt die Menge abfragen
select ..
Code:
(voranstehende Leerzeile)select .. 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) |
AW: SQL-Statement doesn't return rows
Zitat:
|
AW: SQL-Statement doesn't return rows
Das Fangen der Exception wäre aber eine zumutbare Option, finde ich.
|
AW: SQL-Statement doesn't return rows
Zitat:
Wir können ruhig die Kirche im Dorf lassen oder? |
AW: SQL-Statement doesn't return rows
Zitat:
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz