Fehlermeldung bei Eintrag in DB

[zeras]

Hallo,

ich möchte Daten aus Exceltabellen auslesen und in eine DB schreiben.
Das Auslesen klappt, nur beim Einfügen in die DB kommt es immer wieder zu Fehlermeldungen.
Es sieht so aus, als wenn die Inhalte aus manchen Feldern Zeichen enthalten, die Firedac "falsch" interpretiert.
Ich möchte die Daten aus den Excelfeldern genauso in eine DB schreiben, dass ich gegebenenfalls wieder eine Exceltabell mit selbem Inhalt erzeugen kann.
Außerdem möchte ich aber auch in den Daten in der DB suchen.

Delphi-Quellcode:

    SqlState := Format('INSERT INTO %s (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s) VALUES(%d, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s);',
                   [TableNameKANummer,
                    feldKANummer,
                    ...............
                    QuotedStr(KAdata.McTyp),
                    ...............

Ich habe letztens gelesen, dass man QuotedStr nicht nutzen soll. Aber wie kann ich die Daten so in die DB schreiben, dass es keine Fehlermeldung gibt?

[haentschman]

Moin...:P

Zitat:

Aber wie kann ich die Daten so in die DB schreiben, dass es keine Fehlermeldung gibt?

Parameter! :warn:

Delphi-Quellcode:

Qry.SQL.Text := 'insert into Blubb (Bla) values(:Bla)';
Qry.ParamByName('Bla').AsString := Feldwert;

[zeras]

Zitat:

Zitat von haentschman (Beitrag 1481663)

Delphi-Quellcode:

Qry.SQL.Text := 'insert into Blubb (Bla) values(:Bla)';
Qry.ParamByName('Bla').AsString := Feldwert;

Danke, das hat funktioniert. Werde das bei meinen nächsten Abfragen beachten.

[himitsu]

Und QuoteStr solltest du unbedingt vergessen.
Irgendwo hat jede DB-Komponente eine Quote/Escape-Funktion, welche man unbedingt nutzen sollte. (wenn es nicht anders geht und man auf Biegen und Brechen SQLs manuell bauen will)

QuoteStr ist ausschließlich für PascalStrings da, nach der Syntax von Pascal/Delphi-Quellcode,
aber diese SQL-Syntax ist etwas komplett Anderes.


Tipp: Komm mal auf soeine "doofe" Idee, wie einer unserer Kunden, welche in alphanumerischen Artikelnummern nun auch noch ein ' verwenden wollten.
Die SQL-Params waren nicht das Problem, da wir (meistens) kein QuoteStr mehr für DB-Aufgaben nutzen, aber bei Übergabe ans Python, da rauchte QuoteStr wunderschön ab.

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1481717)

Irgendwo hat jede DB-Komponente eine Quote/Escape-Funktion, welche man unbedingt nutzen sollte. (wenn es nicht anders geht und man auf Biegen und Brechen SQLs manuell bauen will)

Es gibt Szenarien, die durch Parameter nicht abgedeckt werden können, etwa "IN" mit einer variablen Anzahl Einträge. Wohl dem, dessen Datenbank temporäre Tabellen unterstützt: dann muss die SQL-Anweisung zerlegt werden die Erstellung einer temporären Tabelle mit einer Spalte, die die "IN-Werte" aufnimmt, das Füllen dieser Tabelle mit den Werten per INSERT mit Parameter und einem anschließenden Umbau der ursprünglichen Abfrage auf "IN (SELECT x FROM tmp)" oder auch einem JOIN.

[himitsu]

Alle DBs haben APIs für Array-Parameter.
OK, in vielen DB-Komponenten ist das leider nicht eingebaut.

Na gut, in dem Fall bauen wir auch den String zusammen, geben ihn mit ParamByName als ein String rein und zerlegen ihn dann db-seitig in ein Array/Rows
oder er geht via MakroByName rein, aber da sind es meistens bloß Integer-Arrays und wenn nicht, dann wird wenigstens die "richtige" API verwendet.
z.B. pg_escape_string/pg_escape_literal oder TPgTextConverter.EscapeString

[generic]

Zitat:

Zitat von zeras (Beitrag 1481662)

Hallo,

Delphi-Quellcode:

    SqlState := Format('INSERT INTO %s (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s) VALUES(%d, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s);',
                   [TableNameKANummer,
                    feldKANummer,
                    ...............
                    QuotedStr(KAdata.McTyp),
                    ...............

Ich habe letztens gelesen, dass man QuotedStr nicht nutzen soll. Aber wie kann ich die Daten so in die DB schreiben, dass es keine Fehlermeldung gibt?

Die Kollegen haben dir nur gezeigt, wie es besser geht, aber leider nicht gesagt was du das falsch machst.
Man baut SQLs NIEMALS als String zusammen und schon gar nicht, fügt man die Daten dort ein! Das ist ein NOGO!
Du erzeugt damit die Möglichkeit SQL-Injections zu machen. Das solltest du ganz dringend mal erforschen und nachlesen!
SQL-Injections werden übrigens viel eingebaut, weil viele das nicht richtig über Parameter lösen. Dadurch ist SQL-Injection eine der größten Sicherheitsprobleme, welche eingebaut werden:
siehe https://owasp.org/www-project-top-te...2017-Injection

[zeras]

Zitat:

Zitat von generic (Beitrag 1481855)

Die Kollegen haben dir nur gezeigt, wie es besser geht, aber leider nicht gesagt was du das falsch machst.
Man baut SQLs NIEMALS als String zusammen und schon gar nicht, fügt man die Daten dort ein! Das ist ein NOGO!
Du erzeugt damit die Möglichkeit SQL-Injections zu machen. Das solltest du ganz dringend mal erforschen und nachlesen!
SQL-Injections werden übrigens viel eingebaut, weil viele das nicht richtig über Parameter lösen. Dadurch ist SQL-Injection eine der größten Sicherheitsprobleme, welche eingebaut werden:
siehe https://owasp.org/www-project-top-te...2017-Injection

Danke für die Hinweise.
Da ich nicht so viel mit DB'S arbeite, habe ich mir den String zusammengebaut, damit ich sehe, was an die DB übergeben wird. An SQL Injection hatte ich dabei nicht gedacht.
Die Programme, wo ich DB's benutze, helfen mir bei meiner Arbeit. Jemand anderes wüsste garnicht, was man damit machen kann.
Aber man kann ja trotzdem von euch Profis lernen.

[himitsu]

Nicht nur absichtliche SQL-Injections.
Schon alleine eine "falsche" Kodierung/Escaping können das SQL zerstören und das Programm wunderschön abrauchen lassen.

Siehe mein Beispiel mit ' in Texten.