Hochkomma entfernen -> INSERT INTO-Problem

[HolgerCW]

Danke für die Tips,

werde ich gleich umsetzen.

Bei Xong-Code kommt aber der Fehler bei:

Spalten.QuoteChar := ''; -> Inkompatible Typen 'Char' und 'string'

[Xong]

Zitat von HolgerCW:

Bei Xong-Code kommt aber der Fehler bei:

Spalten.QuoteChar := ''; -> Inkompatible Typen 'Char' und 'string'

Dann nutze ein neutrales Leerzeichen:
Spalten.QuoteChar := ' '; LG,
Xong

[HolgerCW]

Alles klar,

eine Frage habe ich noch. Kann man TStrings nur mit Add füllen oder kann man die auch in etwa so übergeben: [Variable1,Variable2,...] ?

Müsste sonst nämlich alle Aufrufe der Procedure Datensatz_insert komplett ändern.

Gruss

Holger

[DeddyH]

Versuch es mal mit Array of String (ohne Gewähr).

[Xong]

Zitat von HolgerCW:

eine Frage habe ich noch. Kann man TStrings nur mit Add füllen oder kann man die auch in etwa so übergeben: [Variable1,Variable2,...] ?

Müsste sonst nämlich alle Aufrufe der Procedure Datensatz_insert komplett ändern.

Wenn du die Werte in den Strings Spalten und Werte kommasepariert hast, kannst du die Prozedur auch aufrufen, ohne ihren Kopf zu verändern.

Folgende Prozedur hat den gleichen Kopf, wie du ihn vorgegeben hattest:

Delphi-Quellcode:

procedure Datensatz_insert (Werte:String; Spalten:String; Tabelle:String);
var i: Integer;
    sValues,sWerte,sSpalten: TStrings;
begin
  sValues := TStrings.Create;
  sWerte := TStrings.Create;
  sSpalten := TStrings.Create;

  sSpalten.Delimiter := ',';
  sSpalten.QuoteChar := ' ';
  sValues.Delimiter := ',';
  sValues.QuoteChar := ' ';

  sSpalten.CommaText := Spalten;
  sWerte.CommaText := Werte;

  for i:=0 to sSpalten.Count-1 do
    sValues.Add(':' + sSpalten[i]);

with DM_Query_XYZ do
begin
  QueryInsert.Close;
  QueryInsert.Add('INSERT INTO ' + Tabelle);
  QueryInsert.Add('(' + sSpalten.DelimitedText + ')');
  QueryInsert.Add('VALUES(' + sValues.DelimitedText + ')');
 
  QueryInsert.Prepare;

  for i:=0 to sSpalten.Count-1 do
    QueryInsert.ParamByName(sSpalten[i]).Asstring := sWerte[i];

  QueryInsert.Execute;
end;

LG,
Xong

[HolgerCW]

Wenn der Debugger diese zeile erreicht:

sSpalten.CommaText := Spalten; kommt die Fehlermeldung: Abstrakter Fehler ???

So sieht mein Spaltenstring aus: 'STOER_ART_ID,ANWENDER_ID, DATUM, MELDER, ORT_ID, ... '

[nahpets]

versuchs mal mit DelimitedText statt CommaText.

[Sherlock]

Zitat von Phoenix:

Zitat von HolgerCW:

Vielen dank für die Infos.
Habe da aber leider ein Problem. Ich nutze für mein ganzes Programm beim INSERT folgende Procedure:
Wie könnte ich diese umbauen, damit es klappt ? Will jetzt nicht mein ganzes Programm ändern.

Aua. Dieser Code ist nicht nur ein Abmahnungsgrund, sondern sogar einer für eine fristlose Kündigung.

Was, wenn ein Benutzer z.B. bei einem der einzugebenden Werte folgendes eingibt:

Code:

; DROP TABLE nameeinerwichtigentabelle; --

?
Du öffnest damit dem einfachsten aller Angriffe, namentlich der SQL Injection, sämtliche Türen. Also. Umbauen auf Parameter und nirgends in der Anwendung auf die Idee kommen, SQL anhand von Benutzereingaben zusammenzubauen. Das ist das allerschlimmste was man tun kann.

Darf ich mal kurz dazwischen ein gepflegtes "Nö" einwerfen?

Vielleicht klappt sowas mit Datenbankclients die es nicht interessiert, daß alle Befehle fehlerfrei ausgeführt werden sollten, bevor sie den nächsten ausführen. Aber bei Oracle sehe ich diese Gefahr nicht. Angenommen es soll folgendes passieren:
update customer set name = 'Willi'; Wenn jetzt der Tabellenname durch eine Variable gefüllt wird, die das hier beinhaltet
; DROP TABLE nameeinerwichtigentabelle; -- dann würde man ja dieses hier bekommen:
update ; DROP TABLE nameeinerwichtigentabelle; -- set name = 'Willi'; Und das gibt dann eine Exception mit einem Oraclefehler (Nummer weiss ich nicht, aber sinngemäß kommt da: Befehl nicht korrekt beendet, und der Rest wird gar nicht mehr ausgeführt. Ich weiss nicht wie das MySQL und Konsorten handhaben, aber wenn die soo leicht hinters Licht zu führen sind...hats vielleicht doch einen Grund Geld für ein DBMS zu zahlen.

Selbstverständlich sollte man lieber mit Parametern arbeiten, wegen Übersichtlichkeit und auch aus Performancegründen (Querys, bei denen sich nur die Inhalte der Paramter ändern werden schneller ausgeführt, als wenn man die gleiche Query mit unterschiedlichen Inhalten absendet.

Sherlock

[DeddyH]

Und wenn man statt des Tabellennamens den Wert hernimmt? Bei fehlender Prüfung und genügend krimineller Energie bekommt man dann so etwas hin:update customer set name = 'Willi';DROP TABLE WichtigeTabelle;update customer set name = 'Wuppdi';

[Sherlock]

Aaaah, Rückzug!

Aber ne Abmahnung oder Kündigung gibts dafür trotzdem nicht, denn der Chef hat noch weniger Ahnung davon als ich

Sherlock