Sehr oft bekommt man Codes wie diesen zu Gesicht:
Wenn ich nun in Textbox1 "Heinz" eingebe, und in Textbox2 "Hacker", so erhalte ich als Wert von sSql dieses:So ist das wohl gedacht, und in Ausführung wird das einen Datensatz in die Tabelle `User` schreiben.

Was aber, wenn ein Bösewicht in Textbox2 nun folgendes komisches als "Nachname" eintippt: Hacker'); DROP TABLE `User`; --

Dann erhalte ich sSql als:Das sind nun zwei Sql-Kommandos in einer Zeile.
Und - bitte hinschauen! - in Ausführung löscht das zweite Kommado die Tabelle `User`
ups!

Ja, so geht Sql-Injection
Ich hoffe, nun klar, wie kriminell fahrlässig es ist, Sql-Statements veränderlichen Inhalts ohne Verwendung von DbParametern an eine Datenbank zu senden.

Scheint aber kaum einen zu jucken.
Mach einfach mal eine Forum-Suche nach "Insert Into" - dann siehst du, wieviele das "wissen"

Aber wie in Post#1 im "Nachworte"-Spoiler bereits ausdrücklich erbeten:
Ich würde dieses Tut gerne konzentriert erhalten und nicht zerlabern, auch nicht mit der Erörterung korrekter Vorgehensweisen.

Der korrekte Ansatz ist ja genannt: DbParameter.
Und ich wiederhole: Ich möchte das hier nicht erörtern, denn es gibt viele Möglichkeiten der Umsetzung. Manche, händische sind sehr umständlich, andere recht elegant, und beziehen DataAdapter, CommandBuilder, Databinding, Extension-Functions oder typisierte TableAdapter mit ein.

Die meiner Meinung nach Minimal-Lösung, mit Extension-Functions, ist hier gezeigt: Tipp & Trick: DbParameter
Dort ist übrigens auch ein viel leistungsfähigerer Datenzugriff gezeigt, der Databinding unterstützt, und noch weitere Probleme löst, die hier noch garnet erwähnt sind.
(Edit: Die leight-weigth-Variante des Letzteren gibts neuerdings hier: Dataset->Db )

Jdfs. in diesem Tut sei einzig auf den Punkt gebracht, und ohne Verwässerung herausgestellt und begründet, dass Db-Zugriffe ohne DbParameter ein Ausmaß an Fahrlässigkeit darstellen, das wirklich ans kriminelle grenzt - bedenkt man die Schäden, die daraus entstehen können.