STR_REPLACE in Verbindung mit mysql

[Janett]

Hi und hallo,

folgendes Problem kann ich nicht lösen.

Aus einem Formularfeld werden Daten in dieser FORM gesendet
21:111:22

Dieser Wert soll mit div. anderen in eine kleine DB-Tabelle.
Da bei meinen ersten Versuchen am : gemeckert wurde, habe ich ein str_replace benutzt. Der : soll nun durch ein _ ersetzt werden. Funktioniert.

Doch bei speichern des Wertes in der DB bekomme ich diese Meldung:
Unknown column '11_22_33' in 'field list'

Das es diese Spalt nicht gibt ist mir klar.
So sieht der query aus.

...
$planet = str_replace(":","_",$_POST['planet']);
    mysql_query("INSERT INTO planeten (player,universum,planet) VALUES (".$_GET['player'].",".$_POST['universum'].",".$planet." )" ) or die (mysql_error());
...

ICh weiß es fehlen noch div. Sicherheitssachen, die kommen aber später.
Was könnte mein Problem in dem o.g. Fall sein?

Dank für eure Hilfe
eure Janett

[wahsaga]

hi,

Doch bei speichern des Wertes in der DB bekomme ich diese Meldung:
Unknown column '11_22_33' in 'field list'

Das es diese Spalt nicht gibt ist mir klar.

Warum benutzt du es dann als Spaltennamen?

Was könnte mein Problem in dem o.g. Fall sein?

RTFM

gruß,
wahsaga

[Cheatah]

Hi,

Da bei meinen ersten Versuchen am : gemeckert wurde, habe ich ein str_replace benutzt.

ein Fehler wird immer nur dort erkannt, wo der Parser nicht mehr weiterkommt, niemals dort, wo die Ursache liegt.

Der : soll nun durch ein _ ersetzt werden. Funktioniert.

Ist aber trotzdem falsch.

So sieht der query aus.
    mysql_query("INSERT INTO planeten (player,universum,planet) VALUES (".$_GET['player'].",".$_POST['universum'].",".$planet." )" ) or die (mysql_error());

Das ist kein Query, sondern PHP-Code. Dieser spielt für die Datenbank nicht die geringste Rolle; erstens kann sie kein PHP, zweitens erfährt sie niemals etwas von diesem Code. Wie lautet das SQL-Statement, und wie _müsste_ es lauten?

Cheatah

[Tom]

Hello Cheatah,

Das ist kein Query, sondern PHP-Code. Dieser spielt für die Datenbank nicht die geringste Rolle; erstens kann sie kein PHP, zweitens erfährt sie niemals etwas von diesem Code. Wie lautet das SQL-Statement, und wie _müsste_ es lauten?

Unknown column '11_22_33' in 'field list'

Seit wann ist das eine PHP-Fehlermeldung?

Auch wenn das bei Janett unaufgeräumt aussieht, hat es das Script doch geschafft, sich bis zur Datenbank durchzukämpfen und auch deren Fehlermeldung zurückzuliefern;-)

@Janett:

Damit das etwas aufgeräumter aussieht:

$sql = "INSERT INTO planeten ".
         "(player,universum,planet) ".
         "VALUES (".
                    $_GET['player'].
                  ",".
                    $_POST['universum'].
                  ",".
                    $planet.
                  " )"

## Ich habe nichts korrigiert am Statement

mysql_query($sql, $con) or
       die ( 'Query '.htmlentities($sql,ENT_QUOTES).
             "<br>\n".mysql_error()
           );

Bei Fehler das SQL-Statement wieder mit ausgeben lassen.
Das hilft oft mehr, als die MySQL-Fehlermeldung

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cheatah]

Hi,

Das ist kein Query, sondern PHP-Code. Dieser spielt für die Datenbank nicht die geringste Rolle; erstens kann sie kein PHP, zweitens erfährt sie niemals etwas von diesem Code. Wie lautet das SQL-Statement, und wie _müsste_ es lauten?
Unknown column '11_22_33' in 'field list'
Seit wann ist das eine PHP-Fehlermeldung?

ist es nicht. Und genau deshalb ist der PHP-Code auch vollkommen uninteressant.

Auch wenn das bei Janett unaufgeräumt aussieht, hat es das Script doch geschafft, sich bis zur Datenbank durchzukämpfen und auch deren Fehlermeldung zurückzuliefern;-)

Und solange man nur den PHP-Code betrachtet, wird man es schwer haben, den SQL-Fehler zu finden.

Damit das etwas aufgeräumter aussieht:

Uninteressant! Das Problem liegt offensichtlich am SQL-Code, also hör *bitte* auf, Dich auf den PHP-Code zu konzentrieren. Dies gilt sowohl Dir als auch Janett.

Bei Fehler das SQL-Statement wieder mit ausgeben lassen.
Das hilft oft mehr, als die MySQL-Fehlermeldung

Genauer gesagt: Bei SQL-Problemen den PHP-Code zu betrachten ist ebenso widersinnig, wie bei HTML-, CSS- oder JavaScript-Problemen PHP-Code beizubehalten. Genauso gut könnte man den Code ausdrucken und die Maserung des Papiers begutachten, um dem Problem auf die Spur zu kommen.

Cheatah

[Tom]

Hello,

Uninteressant! Das Problem liegt offensichtlich am SQL-Code, also hör *bitte* auf, Dich auf den PHP-Code zu konzentrieren. Dies gilt sowohl Dir als auch Janett.

Du bist aber heute unkenzentriert!
Wenn ich das von PHP generierte SQL-Statement sehen will kann ich doch PHP dazu verwenden, es anzeigen zu lassen. Was nörgelst Du also herum? Mein Vorschlag zielte genau darauf!

Bei Fehler das SQL-Statement wieder mit ausgeben lassen.
Das hilft oft mehr, als die MySQL-Fehlermeldung

Genauer gesagt: Bei SQL-Problemen den PHP-Code zu betrachten ist ebenso widersinnig, wie bei HTML-, CSS- oder JavaScript-Problemen PHP-Code beizubehalten. Genauso gut könnte man den Code ausdrucken und die Maserung des Papiers begutachten, um dem Problem auf die Spur zu kommen.

Ich versteh nicht, was Du willst!

Wenn das MySQL-Statement mittels PHP zusammengestellt wird, muss ich mir doch anschauen, wie und wo das geschieht. Wie soll ich denn sonst an ein dynamisch generiertes Statement herankommen, wenn nicht durch eine geeignete Kontrollausgabe zur Laufzeit?

Leg Dich ins Bett und schlaf Dich aus.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Wenn das MySQL-Statement mittels PHP zusammengestellt wird, muss ich mir doch anschauen, wie und wo das geschieht. Wie soll ich denn sonst an ein dynamisch generiertes Statement herankommen, wenn nicht durch eine geeignete Kontrollausgabe zur Laufzeit?

Also, was interessiert uns - PHP-Code, oder Kontrollausgabe des Statements?

gruß,
wahsaga

[Cheatah]

Hi,

Du bist aber heute unkenzentriert!

nein, Unken interessieren mich eigentlich gerade sehr wenig ;-)

Wenn ich das von PHP generierte SQL-Statement sehen will kann ich doch PHP dazu verwenden, es anzeigen zu lassen. Was nörgelst Du also herum? Mein Vorschlag zielte genau darauf!

Ich "nörgele" vor allem an dem Versuch herum, die gedankliche Trennung zwischen den unterschiedlichen Techniken zu verschmieren, die jedoch unbedingt erfolgen *muss*, wenn man sie einsetzt.

Genauer gesagt: Bei SQL-Problemen den PHP-Code zu betrachten ist ebenso widersinnig, wie bei HTML-, CSS- oder JavaScript-Problemen PHP-Code beizubehalten. Genauso gut könnte man den Code ausdrucken und die Maserung des Papiers begutachten, um dem Problem auf die Spur zu kommen.
Ich versteh nicht, was Du willst!

Siehe oben. Einem Entwickler muss *unbedingt* klar sein, welche Technik er zu betrachten hat, wenn es zu einem Problem kommt. Dein vorgeschlagener Code ist diesbezüglich meiner Ansicht nach kontraproduktiv.

Wenn das MySQL-Statement mittels PHP zusammengestellt wird, muss ich mir doch anschauen, wie und wo das geschieht.

Nein. Nein! Zuerst einmal muss etwas völlig anderes betrachtet werden, was nicht das geringste mit PHP zu tun hat! Dir mag das klar sein - dem OP jedoch offensichtlich nicht.

Wie soll ich denn sonst an ein dynamisch generiertes Statement herankommen, wenn nicht durch eine geeignete Kontrollausgabe zur Laufzeit?

Wie soll man begreifen, dass diese ausgegebene Kontrolle *KEINEN* Zusammenhang zu PHP hat, wenn ständig darauf gepocht wird, das SQL-Problem mit PHP-Code zu lösen?

Leg Dich ins Bett und schlaf Dich aus.

Dito. Denke bitte daran, dass das Forenmotto "Energie des Verstehens" heißt, nicht "Energie des Kopierens". Dein Vorschlag verhindert IMHO sehr effektiv eben dieses Verstehen.

Cheatah

[Tom]

Hello,

Dito. Denke bitte daran, dass das Forenmotto "Energie des Verstehens" heißt, nicht "Energie des Kopierens". Dein Vorschlag verhindert IMHO sehr effektiv eben dieses Verstehen.

Ich entnehme jetzt zwischen den Zeilen dieses ganzen Hin und Her, dass Du Janett eigentlich anraten wolltest, ein Test-Statement direkt in einem Datenbank-Frontend (also auf der Konsole oder in einem Tool) an die Datenbank abzusetzen?

Wenn das so ist, wieso sagst Du das dann nicht deutlich?

Wie soll man hier Energie fürs Verstehen entwickeln, wenn Du unverständliche Postings fomulierst?

https://forum.selfhtml.org/?t=150172&m=975629

Du suggerierst in Deinem Posting, dass die Fehlermeldung vom Parser stammen würde.
Der hat aber gar keinen Fehler erkannt, sondern nur eine Meldung weitergeleitet, die von der Datenbank stammt, genauso, wie er im Script dazu beauftragt wurde!

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Ich entnehme jetzt zwischen den Zeilen dieses ganzen Hin und Her, dass Du Janett eigentlich anraten wolltest, ein Test-Statement direkt in einem Datenbank-Frontend (also auf der Konsole oder in einem Tool) an die Datenbank abzusetzen?

Erst mal, sich anzuschauen, _was_ sie da eigentlich an die Datenbank übergibt.
Ja, der Ort und Zeitpunkt dazu ist sicherlich im PHP-Script, wo diese Query an die Datenbank übergeben wird - hat aber mit PHP selber absolut keinen Zusammenhang.

Wenn das so ist, wieso sagst Du das dann nicht deutlich?

Erstens ist dem ja nicht so - und zweitens stellt eine (in meinen Augen) gute Antwort die Fragen, die sich der Frager eigentlich selbst hätte stellen müssen - was dieser aber versäumt hat oder wozu er nicht in der Lage war.
Dann hat er also erst mal die richtigen Fragen - jetzt ist es wieder sein Part, über die richtigen Antworten darauf nachzudenken.

https://forum.selfhtml.org/?t=150172&m=975629

Du suggerierst in Deinem Posting, dass die Fehlermeldung vom Parser stammen würde.

Nein, das hat Cheatah nicht - nicht so, wie du es verstehen willst.
Er hat darauf hingewiesen, dass die gemeldete Stelle nicht die Fehlerhafte sein muss (selten sein wird) - sondern lediglich die, an der der Parser nicht mehr weiterkommt. Mit Parser meint er hier den DB-seitigen Mechanismus, der die übergebene Query erst mal syntaktisch analysiert, um zu ermitteln, was eigentlich erfragt werden soll.

Der hat aber gar keinen Fehler erkannt, sondern nur eine Meldung weitergeleitet, die von der Datenbank stammt, genauso, wie er im Script dazu beauftragt wurde!

Das hat der PHP-Parser gemacht, ja.
Der interessiert hier aber nicht, weil ein MySQL-Problem vorliegt - genau darauf versucht Cheatah ja die ganze Zeit hinzuweisen.

gruß,
wahsaga

[Tom]

Hello,

Dein Problem ist ein anders...

1. Übergabeformat von Werten in einem SQL-Query
2. Escaping von SQL-Werten
3. Injection-Probleme bei der Daten Übernahme ins Script

Aus einem Formularfeld werden Daten in dieser FORM gesendet
21:111:22

Dann solltest Du die geposteten Daten als erstes mal wieder ausgeben in einem "Affenformular" (siehe Archiv) und ein wenig damit spielen.
Da kommen dann bestimmt noch mehr Fragen hoch. :-)

Dieser Wert soll mit div. anderen in eine kleine DB-Tabelle.
Da bei meinen ersten Versuchen am : gemeckert wurde, habe ich ein str_replace benutzt. Der : soll nun durch ein _ ersetzt werden. Funktioniert.

Warum Daten verändern, wenn man sie auch ordentlich eintragen kann?

Doch bei speichern des Wertes in der DB bekomme ich diese Meldung:
Unknown column '11_22_33' in 'field list'

Was sagt uns das? Das Feld mit dem Namen ist nicht in der Feldliste (der Tabelle) enthalten.

Um Strings zu übergeben, muss man was tun? Richtig: man muss sie in Häkchen übergeben.
Was ist aber nun, wenn ein Häkchen im String drinsteckt? Shit!
Dann muss man den String vorher behandeln

Dafür gibt es bei MySQL die Funktion mysql_real_escape_string()

Und weil die so gut funktioniert, und man ja nie weiß, was in einm String drinsteckt, behandelt man sicherheitshalber jeden Feldwert damit, nur NULL und SQL-Funktionen nicht

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[rob]

Hi!

Warum schreibt du denn das Datum mit Unterstrichen in die DB?
Wenn du das da anders reinsetzt, hast du die Mgölichkeit, dein Datum später einfacher weiter zuveratbeiten. Bei MySQL gibt es dafür extra Feldtypen.
MySQL bietet darüber hinaus auch selbst einige Datums-/Zeit-Funktionen.

habe ich ein str_replace benutzt. Der : soll nun durch ein _ ersetzt werden. Funktioniert.

Ja, das ist möglich. Es wäre allerdings auch möglich, String nicht mit PHP zu ersetzen, sondern das von MySQL machen zu lassen.
Schau mal im MySQL-Handbuch nach REPLACE (INTO).

$planet = str_replace(":","_",$_POST['planet']);
    mysql_query("INSERT INTO planeten (player,universum,planet) VALUES (".$_GET['player'].",".$_POST['universum'].",".$planet." )" ) or die (mysql_error());

Das es diese Spalt nicht gibt ist mir klar.

Na gut. Wo ist dann dein Problem? Die Fehlermeldung ist doch eindeutig.
Ich verstehe nicht ganz, wo du nicht weiterkommst.

ICh weiß es fehlen noch div. Sicherheitssachen, die kommen aber später.
Was könnte mein Problem in dem o.g. Fall sein?

Nie, nie, niemals Daten, die von außen kommen, einfach ungeprüft übernehmen und weiterverarbeiten.
In $_GET['player'] oder $_POST['universum'] keine potentiell gefährlichen Zeichen wie z.B. ein Backslash enthalten sind. In deinen Variablen darf auch in gar keinem Fall MySQL-Code entahleten sein.
Mit dieser Abfrage ist deine Seite offen für einen Angriff mittels SQL-Injection: http://de.wikipedia.org/wiki/SQL-Injektion
Benutze Funktionen wie mysql_real_escape_string(), preg_replace(), addslashes(). Sonderzeichen müssen in jedem Fall escaped werden, um etwaigen SQL-Code unschädlich zu machen.

Gruß,
rob