Fehler bei Einfügen von Daten in der DB

Y

yuro

Erfahrenes Mitglied
Hej,

ich frag mich was in meinem PHP code falsch ist, dass er einfach keine Daten aus meinem Formular in die DB einfügt?

Code:
PHP: 
<?php
		$vorname = $_POST['vorname'];
		$nachname = $_POST['nachname'];
		$wann_es_geschah = $_POST['wannesgeschah'];
		$wie_lange = $_POST['wielange'];
		$wie_viele = $_POST['wieviele'];
		$alien_beschreibung = $_POST['alienbeschreibung'];
		$was_sie_taten = $_POST['wassietaten'];
		$fang_gesehen = $_POST['fanggesehen'];
		$email = $_POST['email'];
		$weiteres = $_POST['weiteres'];
		
		$db = mysqli_connect('localhost', 'root', '', 'aliendatenbank') 
		or die('Fehler beim Verbinden mit MySQL Server.');
		
		$sql = "INSERT INTO alien_entfuehrung(vorname, nachname, wann_es_geschah, wie_lange, wie_viele, alien_beschreibung, was_sie_taten, fang_gesehen, weiteres, email) VALUES('$vorname', '$nachname', '$wann_es_geschah', '$wie_lange', '$wie_viele', '$alien_beschreibung', '$was_sie_taten', '$weiteres', '$email')";
		
		echo $sql;
		
		$ergebnis = mysqli_query($db, $sql) 
		or die('Fehler bei Datenbankabfrage.');
		
		mysqli_close($db);

ständig wirft er Fehler bei Datenbankabfrage raus.
 
@mermshaus

ich gehe gerade ein Tutorial durch. Das mit den SQL Injections kommt erst später. Nur laut buch müsste der Code funktionieren. Leider aber nicht bei mir :(
 
yuro hat gesagt.:
Das kam jetzt dabei raus. "Column count doesn't match value count at row 1"
Zum Vergrößern anklicken....

Siehst du, da hast du deinen Fehler ;-) Die Anzahl der VALUES stimmt nicht mit der Anzahl der Spalten überein, in die MySQL was rein schreiben soll. Es fehlt ein Wert für die Spalte "fang_gesehen".

Im Übrigen pflichte ich mermshaus bei. Du solltest auf jeden Fall deine Variablen escapen. Wobei ich immer noch denke, dass diese Funktion eine Krücke ist und endlich durch Prepared Statements ersetzt werden sollte.
 
Ok hab den Fehler gefunden... in der insert anweisung hab ich $fang_gesehen vergessen einzutragen. :) dankeeee für eure Hilfe :)
 
Was ist das für ein Buch, was dir erst beibringt, wie man unsicheren Code baut, dann alles verwirft und ganz anders ans Werk geht? :ugly:

Was die Jungs oben sollen wollen: Du hast 10 Felder in der Query, aber nur 9 Values,- das sagt auch der SQL-Error aus ;)
 
saftmeister hat gesagt.:
Wobei ich immer noch denke, dass diese Funktion eine Krücke ist und endlich durch Prepared Statements ersetzt werden sollte.
Zum Vergrößern anklicken....

Ich denke, die Funktion muss existieren, weil es mit dem API möglich sein sollte, Statements auch – äh – unprepared abzusetzen. Das ist schließlich ein Feature, das die Datenbanksysteme anbieten.

Prepared Statements kennt mysqli ja auch. (Leider ist der Teil des Interfaces so grottig, dass man das eigentlich nicht ohne Wrapper nutzen will.) Es liegt am Anwender, die zu nutzen oder nicht zu nutzen. Das ist kaum pauschal zu beantworten. Siehe etwa:

- http://www.php.de/php-fortgeschrittene/54741-prepared-statements-immer-einsetzen.html

Vielleicht kann man festhalten: Um Prepared Statements zu nutzen, braucht es schnell mehr Infrastruktur-Code, der so in der Standardbibliothek von PHP nicht drin ist. Ich denke da etwa auch daran, was man mit dynamisch generierten Query-Strings macht.

bofh1337 hat gesagt.:
Was ist das für ein Buch, was dir erst beibringt, wie man unsicheren Code baut, dann alles verwirft und ganz anders ans Werk geht? :ugly:
Zum Vergrößern anklicken....

Na ja, alles verwerfen muss man nicht. Es reicht, die Escaping-Funktionen hinzuzufügen.

Für Bücher/Tutorials/Vermittlung sind Ausnahmefälle immer ein kleines „Problem“. Ich finde auch, dass es von Beginn an dazugehört. Man muss sich aber vor Augen führen, dass entsprechender Code die Beispiele und Erklärungen teilweise ganz schön aufbläht. Ich habe ein gewisses Verständnis dafür, das nacheinander abzuhandeln, aber optimal finde ich es auch nicht. Andererseits kannst du als Autor auch wenig tun, wenn der Leser nach 10 von 20 Seiten das Kapitel zuklappt.
 
mermshaus hat gesagt.:
Ich denke, die Funktion muss existieren, weil es mit dem API möglich sein sollte, Statements auch – äh – unprepared abzusetzen. Das ist schließlich ein Feature, das die Datenbanksysteme anbieten.
Zum Vergrößern anklicken....

Da die Frage beantwortet wurde, kann man etwas OT werden: PS löst nicht nur das Problem der unescapten Daten. Sie bringen auch Performance-Vorteile und bessere Wartbarkeit durch übersichtlicheren Code. Lieber 3 Zeilen mit bind_param, als das Zusammengefummel mittels Konkatenation. Das ist nicht nur hässlich, es birgt auch die Anfälligkeit mal was zu übersehen, das beste Beispiel dafür ist die Frage des TO.

mermshaus hat gesagt.:
Prepared Statements kennt mysqli ja auch. (Leider ist der Teil des Interfaces so grottig, dass man das eigentlich nicht ohne Wrapper nutzen will.)
Zum Vergrößern anklicken....

Da kann man geteilter Meinung sein. Was soll es an der Schnittstelle noch zu verbessern geben? Warum sollte man da noch mal was drum herum bauen wollen/sollen/müssen?

Der Vorgang ist klar und einfach zu verstehen: Präparieren, Werte binden, Ausführen, Daten abholen/bzw. bei Write-Operationen Rückgabewerte prüfen.

mermshaus hat gesagt.:
Vielleicht kann man festhalten: Um Prepared Statements zu nutzen, braucht es schnell mehr Infrastruktur-Code, der so in der Standardbibliothek von PHP nicht drin ist.
Zum Vergrößern anklicken....

Beispiel? Was meinst du mit mehr Infrastruktur-Code?

mermshaus hat gesagt.:
Ich denke da etwa auch daran, was man mit dynamisch generierten Query-Strings macht.
Zum Vergrößern anklicken....

Was ist ein dynamischer Query? Ein Query ist ein Query. Der Teil der dynamisch ist, sind die Bindings der Werte. Falls du so krude Sachen wie dynamische Spalten- oder Tabellen-Namen meinst: Dafür gibt es Views bzw. Stored Procedures. IMHO sollte es unnötig sein, einen Query dynamisch aufbauen zu müssen. Da ist was bei der Planung schief gegangen ;-)

mermshaus hat gesagt.:
Na ja, alles verwerfen muss man nicht. Es reicht, die Escaping-Funktionen hinzuzufügen.
Zum Vergrößern anklicken....

Für diesen Fall ja, es handelt sich um ein Tutorial. Sobald es aber mal etwas mehr sein darf und man auf den Trichter kommt, dass durch PS auch mehr Leistung (Wortspiel ;-)) in die Applikation kommt, darf man etliche Funktionen und Scripte umbauen. Dann lieber doch von Anfang an auf PS zurück greifen.

mermshaus hat gesagt.:
Für Bücher/Tutorials/Vermittlung sind Ausnahmefälle immer ein kleines „Problem“. Ich finde auch, dass es von Beginn an dazugehört. Man muss sich aber vor Augen führen, dass entsprechender Code die Beispiele und Erklärungen teilweise ganz schön aufbläht. Ich habe ein gewisses Verständnis dafür, das nacheinander abzuhandeln, aber optimal finde ich es auch nicht. Andererseits kannst du als Autor auch wenig tun, wenn der Leser nach 10 von 20 Seiten das Kapitel zuklappt.
Zum Vergrößern anklicken....

Dann sollte sich der Leser überlegen, ob er die richtige Motivation an den Tag legt. Bei so sicherheitsrelevanten Dingen sollte man gerade Anfängern abverlangen, den richtigen Weg zu gehen. Sonst hat man das 1mrdste Gästebuch, was defaced oder für XSS missbraucht wird. Das kann unser aller Wunsch nicht sein.

Wie bei allem anderen auch: Safety first!
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück