nicht angemeldet
Unknown column 'XXX' in 'field list'
0 0 0 
Tobias Hahner
0 0 Tobias Hahner
0 0 
suit
0
Unknown column 'XXX' in 'field list'
$ysql = 'INSERT INTO ' . ADJUSTMENTS_TABLE . ' (adjustment_value, adjustment_date, member_name, adjustment_reason, adjustment_added_by, adjustment_updated_by, adjustment_group_key, raid_name)
VALUES ($decay_round, $time, $xname, $adjustment_reason, $decay_added_by, NULL, $group_key, $event_post)';
$yresult = $db->sql_query($ysql);
if (!$yresult) {
die("Konnte die Abfrage ADJUSTMENT TABLE nicht ausführen: " . mysql_error());
}
Fehlermeldung:
Unknown column '$decay_round' in 'field list'
PHP 5.3x
Bin neu in php 5.3x hab aber ehrlich gesagt keinen grossen utnerschied zu 4 gefunden. Ich versuch jetzt seit 2 Stunden diesen dummen fehler weg zu bekommen... hab mir mehre sachen durch gelesen und check nicht wo der Fehler ist. BITTE HILFE Ist bestimmt nur ein kleiner dummer syntax fehler ich seh ihn aber nicht :(
-
nachtrag.
SQL einstellungenFeld Typ A ttribute Null Standard
adjustment_id mediumint(8) UNSIGNED Nein auto_increment
adjustment_value float(11,2) Ja NULL
adjustment_date int(11) Nein 0
member_name varchar(30) Ja NULL
adjustment_reason varchar(255) Ja NULL
adjustment_added_by varchar(30) Nein
adjustment_updated_by varchar(30) Ja NULL
adjustment_group_key varchar(32) Ja NULL
raid_name varchar(255) Nein -
Hi,
Fehlermeldung:
Unknown column '$decay_round' in 'field list'
Auch als Neuling solltest schnell erkennen, was das Problem ist - deine Variablen im String wurden nicht ersetzt.
Bin neu in php 5.3x hab aber ehrlich gesagt keinen grossen utnerschied zu 4 gefunden.
Gibt diesbezüglich auch keinen - dir fehlt schlicht und einfach Grundlagenwissen.
Bitte arbeite diese Seite durch, danach bist du schlauer: http://www.php.net/manual/en/language.types.string.php
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
Hallihallo!
$ysql = 'INSERT INTO ' . ADJUSTMENTS_TABLE . ' (adjustment_value, adjustment_date, member_name, adjustment_reason, adjustment_added_by, adjustment_updated_by, adjustment_group_key, raid_name) VALUES ($decay_round, $time, $xname, $adjustment_reason, $decay_added_by, NULL, $group_key, $event_post)'; $yresult = $db->sql_query($ysql); if (!$yresult) { die("Konnte die Abfrage ADJUSTMENT TABLE nicht ausführen: " . mysql_error()); }> > > Fehlermeldung: > > Unknown column '$decay\_round' in 'field list' > > PHP 5.3x Dieser Fehler hat hier nur bedingt etwas mit PHP zu tun, die Meldung wird direkt von MySQL "durchgeschleift". Er besagt, dass es in der Tabelle, die Du hier ansprichst, keine Spalte mit dem Namen '$decay\_round' gibt. Die anderen hier angegebenen Spalten wird MySQL wahrscheinlich auch nicht finden, aber beim jetzigen Stand bricht die Datenbank vorher schon ab. Ich schrieb "bedingt etwas mit PHP zu tun", weil: Du scheinst hier davon auszugehen, dass [innerhalb von single quotes](http://www.php.net/manual/de/language.types.string.php#language.types.string.syntax.single) gefundene Variablennamen durch ihren Wert ersetzt werden. Dem ist aber nicht so. Wenn Du diesen Mechanismus nutzen willst, bieten sich stattdessen [double quotes](http://www.php.net/manual/de/language.types.string.php#language.types.string.syntax.double) an. Aus der Tatsache, dass Du, wie Du schriebst, schon lange versuchst, den Fehler zu finden, schliesse ich, dass es Dir an Erfahrung, evtl auch an Wissen mangelt. Daher gebe ich Dir einmal völlig ungefragt den Tip, Dich mit dem wahrscheinlich wichtigsten Sicherheitsproblem, dem [Kontextwechsel](http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel) vertraut zu machen. Man kann damit nicht früh genug anfangen, denn sonst baut man sich ganz schnell Sicherheitslöcher, die grösser sind als Windows, ICQ und ein offener Waffenschrank gemeinsam. Ganz nebenbei lernst Du in diesem Artikel auch, wie man eine Abfrage, wie Du sie hier bauen möchtest, nicht nur sicher, sondern auch übersichtlich zusammensetzen kannst (achte auf den Teil mit sprintf). Ich hoffe, damit konnte ich helfen. Beste Grüsse, Tobias Hahner-
VIELEN DANK TOBIAS
es waren die double quotes
p.s. die datei ist hinter einem .htaccess versteckt :)
-
Hallihallo!
Gern geschehen :)
p.s. die datei ist hinter einem .htaccess versteckt :)
Es werden also keinerlei Nutzereingaben in $ysql eingesetzt?
Meine Hinweise auf den Kontextwechsel beziehen sich in diesem Deinen Fall auf SQL Injection.Google Dich einfach mal schlau, was da Alles passieren kann...
Beste Grüsse,
Tobias Hahner-
Normal achte ich ja auf so was. Was soll ich sagen. Normal sind auch alle eingaben auf Buchstaben und zahlen limitiert. Wollte schnell sein und hab die neuen SQL Befehle aus nem fertigen viewtopic.php von phpbb3 genommen und nur mit meinen variablen angepasst... das ist da so standart.. ka warum. Ich habs eben nicht verstanden. Dachte passt schon. Sollte ja mit einer .htaccess abgesichert werden. Gestern hab ich mir zu dem das erste mal PHP5 angeschaut und musste schnell gehen weil ich bei einer besprechung was falsch verstanden habe. (Ich Code das umsonst! für eine WoW Gilde.)
Auszug aus einer PHPBB Datei
$sql = 'INSERT INTO ' . BOOKMARKS_TABLE . ' ' . db->sql_build_array('INSERT', array(-
Wollte schnell sein und hab die neuen SQL Befehle aus nem fertigen viewtopic.php von phpbb3 genommen und nur mit meinen variablen angepasst... das ist da so standart..
Weil da an Wrapper herumliegt der vorher die Daten entsprechend behandelt. Standard schreibt man übrigens mit D am Ende.
-
-
-
-
-
Moin!
$ysql = 'INSERT INTO ' . ADJUSTMENTS_TABLE . ' (adjustment_value, adjustment_date, member_name, adjustment_reason, adjustment_added_by, adjustment_updated_by, adjustment_group_key, raid_name) VALUES ($decay_round, $time, $xname, $adjustment_reason, $decay_added_by, NULL, $group_key, $event_post)';Es fehlt am Escaping. Ohne wird das nie was werden. > Bin neu in php 5.3x hab aber ehrlich gesagt keinen grossen utnerschied zu 4 gefunden. Ich versuch jetzt seit 2 Stunden diesen dummen fehler weg zu bekommen... hab mir mehre sachen durch gelesen und check nicht wo der Fehler ist. BITTE HILFE Ist bestimmt nur ein kleiner dummer syntax fehler ich seh ihn aber nicht :( Dein eigentlicher Fehler würde so aber auch mit PHP 4 auftreten, das ist nichts PHP5.3-spezifisches. Die KONSTANTE hast du doch auch als Textwert in den String reingekriegt. Und genau so (plus Escaping-Funktion, [mysqli_real_escape_string](http://php.net/manual/de/mysqli.real-escape-string.php)) machst du das auch mit den $variablen. - Sven Rautenberg-
Und genau so (plus Escaping-Funktion, mysqli_real_escape_string) machst du das auch mit den $variablen.
Aber bitte nur für Strings ;)
-
Hi!
Und genau so (plus Escaping-Funktion, mysqli_real_escape_string) machst du das auch mit den $variablen.
Aber bitte nur für Strings ;)Der Einwand ist unvollständig, weil er so ausgelegt werden kann, dass es bei beispielsweise Zahlen generell nicht nötig sei oder gemacht werden darf. Voraussetzung (für "nicht nötig") ist jedoch, dass sichergestellt ist, dass es wirklich Zahlen sind und nicht nur anzunehmenderweise welche. Und das ist bei PHP nicht so einfach der Fall, wenn es sich um Benutzereingaben handelt. Außerdem schadet es MySQL auch nicht, Zahlenwerte quotiert und maskiert zu verwenden.
Lo!
-
Moin!
Voraussetzung (für "nicht nötig") ist jedoch, dass sichergestellt ist, dass es wirklich Zahlen sind und nicht nur anzunehmenderweise welche. Und das ist bei PHP nicht so einfach der Fall, wenn es sich um Benutzereingaben handelt.
Und was machen intval(), floatval() oder doubleval()?
Schlimmstenfalls kommen da doch falsche Werte an...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
Voraussetzung (für "nicht nötig") ist jedoch, dass sichergestellt ist, dass es wirklich Zahlen sind und nicht nur anzunehmenderweise welche. Und das ist bei PHP nicht so einfach der Fall, wenn es sich um Benutzereingaben handelt.
Und was machen intval(), floatval() oder doubleval()?
Schlimmstenfalls kommen da doch falsche Werte an...Was ist daran schlimm oder falsch, wenn jemand in ein Feld, das für Zahlen vorgesehen ist, was falsches einträgt und dabei 0 rauskommt? Shit in, shit out. Was angebracht ist, muss für den konkreten Anwendungsfall bestimmt werden. Wenn 0 nur ein harmloses Ergebnis liefert, ist es nicht weiter schlimm. Wenn man mit der 0 was ungewolltes anstellen kann, muss diese auch für eine ordentliche Eingabe ausgeschlossen werden. Ich sehe im Moment grad keinen Anwendungsfall, bei dem eine pauschale Typerzwingung problematisch wäre.
Lo!
-
Moin!
Was ist daran schlimm oder falsch, wenn jemand in ein Feld, das für Zahlen vorgesehen ist, was falsches einträgt und dabei 0 rauskommt? Shit in, shit out.
Es kann zu einer "Katastrophe" führen wenn der falsche Datensatz gelöscht oder verändert wird:
Zitat aus "http://php.net/manual/de/function.intval.php"
----------
RückgabewerteDer integer-Wert von var bei Erfolg, sonst 0. Leere Arrays und Objekte als Parameter geben 0 zurück, nichtleere Arrays und Objekte geben 1 zurück.
----------MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Tach auch.
Was ist daran schlimm oder falsch, wenn jemand in ein Feld, das für Zahlen vorgesehen ist, was falsches einträgt und dabei 0 rauskommt? Shit in, shit out.
Es kann zu einer "Katastrophe" führen wenn der falsche Datensatz gelöscht oder verändert wird:
Zitat aus "http://php.net/manual/de/function.intval.php"
Rückgabewerte
Der integer-Wert von var bei Erfolg, sonst 0. Leere Arrays und Objekte als Parameter geben 0 zurück, nichtleere Arrays und Objekte geben 1 zurück.
Das sind die erwähnten Sonderfälle. Wobei ich (um ein Praxisbeispiel zu geben) identifizierenden Spalten (Primary Keys aka "id") meist den Typ "unsigned int" gebe und bei 1 anfange.
Dies bewirkt, dass, wenn ich anhand des PK löschen will und dort die ID "0" suche, gar nichts finde, weil ein entsprechender Datensatz nie in der DB landet.Aber im nicht mehr von dir zitierten Teil steht auch
Wenn man mit der 0 was ungewolltes anstellen kann, muss diese auch für eine ordentliche Eingabe ausgeschlossen werden.
Bis die Tage,
Matti -
Hi!
Was ist daran schlimm oder falsch, wenn jemand in ein Feld, das für Zahlen vorgesehen ist, was falsches einträgt und dabei 0 rauskommt? Shit in, shit out.
Es kann zu einer "Katastrophe" führen wenn der falsche Datensatz gelöscht oder verändert wird:Du hast genau den Teil weggelassen, der sich auf die "Katastrophenfälle" bezieht. Wenn es die gibt, ist nicht die Verwendung von intval() die Ursache sondern ein falscher Programmablauf. Wenn bestimmte Zahlen nicht verwendet werden dürfen, muss man nach irgendwelchen Umwandlungen auf diese Zahlen prüfen, und nicht vorher irgendwas testen und dann den Wert grundlegend verändern.
Lo!
-
Moin!
Wenn bestimmte Zahlen nicht verwendet werden dürfen, muss man nach irgendwelchen Umwandlungen auf diese Zahlen prüfen, und nicht vorher irgendwas testen und dann den Wert grundlegend verändern.
Ja. Aber dennoch wäre ich sehr viel glücklicher wenn intal() und ähnliche Funktionen nicht 0 sondern false zurückliefern würden, wenn es keine Zahl erkennen kann oder auf einen Array losgelassen wird.
Das könnte man dann einfacher feststellen:
if (false===intval($_POST['zahl'])) { Meckere('shit in, shit out!'); }könnte man benutzerfreundlicher reagieren.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
Ja. Aber dennoch wäre ich sehr viel glücklicher wenn intal() und ähnliche Funktionen nicht 0 sondern false zurückliefern würden, wenn es keine Zahl erkennen kann oder auf einen Array losgelassen wird.
Da mach ich dir nicht viel Hoffnung, das sich da was ändert. Einer von PHPs Kollateralschäden ist seine Großzügigkeit, nicht gleich bei jedem Problem eine Fehlermeldung zu werfen, sondern stillschweigend das vermulich richtige zu machen. Dadurch fallen andererseits bestimmte Fehler weniger auf. Kann man aber derzeit nichts machen. Es gibt keine derart verbreitete Alternative, mit der man typsicher programmieren kann.
Das könnte man dann einfacher feststellen:
if (false===intval($_POST['zahl'])) {intval() interessiert sich nicht für Fehler. Dass es bei nicht-leeren Arrays allerdings 1 liefert ist nicht sehr intuitiv. is_numeric() kannst du verwenden, wenn du vorher prüfen willst.
Lo!
-
Moin!
Da mach ich dir nicht viel Hoffnung, das sich da was ändert.
Ich mir auch nicht. Das Kind ist in den Brunnen gefallen und liegt schon Jahre da unten. Ich stelle mir den Aufschrei derjenigen vor, die ihre Joomla, Typo3 und sonstwas für Installationen updaten müssten- und den der Entwickler.
Ich erinnere mich an die verdammt vielen "Wieso geht mein Skript nicht mehr?" / "Warum bekomme ich plötzlich keine Formulardaten mehr?"- Fragen als in PHP 4.3(?) register_globals auf off gesetzt wurde. Und da ging es um Sicherheit. Nur lief halt der unsichere Schrott aus aus so manchem Skriptarchiv nicht mehr...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
Ich erinnere mich an die verdammt vielen "Wieso geht mein Skript nicht mehr?" / "Warum bekomme ich plötzlich keine Formulardaten mehr?"- Fragen als in PHP 4.3(?) register_globals auf off gesetzt wurde. Und da ging es um Sicherheit. Nur lief halt der unsichere Schrott aus aus so manchem Skriptarchiv nicht mehr...
register_globals-on-Scripte sind nicht automatisch Schrott. Das eigentliche Problem war, dass Variablen vor dem Erstgebrauch nicht ausreichend initialisiert wurden. (Abgesehen von wirklichen Fehlern in PHP bei der $GLOBALS-Behandlung.) Wenn man den Grundsatz beachtet kann man auch mit r.g.=on sicher programmieren. Sprich: wenn ein E_ALL im error_reporting in allen Programmsituationen keine Notice-Meldungen wirft, hat man kein r.g.-Problem.
Lo!
-
-
-
-
-
Leute bitte das Problem ist gelöst.. vielen dank noch mal aber reisst euch nicht die köpfe ein :(
-
Moin!
Leute bitte das Problem ist gelöst..
Das wissen wir (und Du) längst: Dein Problem entstand durch die Verwendung des falschen Quota.
vielen dank noch mal aber reisst euch nicht die köpfe ein :(
Das machen wir nicht. Wir führen nur eine informative und sachliche Grundsatzdiskussion über diverse Tatsachen und daraus (nicht oder nicht zwingend) entstehenden Widrigkeiten oder Möglichkeiten um den eigenen Horizont zu erweitern. Du musst also weder befürchten, dass hier Ehen noch dass Freundschaften zerbrechen. Im Gegenteil: Es entstehen diverse Kollegialitäten. Nur der Ton ist so fürchterlich sachlich, dass manche daraus einen erbitterten Streit herleiten - den es aber nicht gibt.
:(
Wieso das denn? Niemand wird Dir die Schuld daran geben, dass Du uns im Sinne eines Stichwortes Gelegenheit gabst über angrenzende Nebenprobleme nachzudenken. Im Gegenteil: Wir kriechen vor Dankbarkeit auf den Knien und bitten Dich: Frag wieder!
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
-
-
-
-
-
-