SQL-Statement doesn't return rows

[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