You have an error in your SQL syntax
H-D Just
- php
ich bekomme immer diese Fehlermeldung:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ','http://gojust.de', 'GoJust', 'Hans-Dieter Just','info@gojust.de', '', '2', '',' at line 3
hier der code wo der fehler sein soll:
1<?php
2
3function check_intersection($x1,$y1,$x2,$y2,$x3,$y3,$x4,$y4)
4
5{
6
7if($y1!=$y2)
8
9{
10
11$m=$x3;
$n=$y3;
$o=$x4;
$p=$y4;
$x3=$x1;
$y3=$y1;
$x4=$x2;
$y4=$y2;
$x1=$m;
$y1=$n;
$x2=$o;
$y2=$p;
}
if($x1<=$x3 && $x2<=$x3) return (1);
if($x1>=$x3 && $x2>=$x3) return (1);
if(($x1<$x3 && $x2>$x3) && ($y1>=$y3 && $y1>=$y4)) return (1);
if(($x1<$x3 && $x2>$x3) && ($y1<=$y3 && $y1<=$y4)) return (1);
return (0);
}
//checking for the free postion
include "common.php";
$sql = "select x1,y1,x2,y2,id from area where cnf_check=0 or cnf_check=1";
$link = mysql_query($sql,$cn);
$num=mysql_num_rows($link);
$check=1;
if($num>0)
{
while($data=mysql_fetch_row($link))
{
$x1=$data[0];
$y1=$data[1];
$x2=$data[2];
$y2=$data[3];
$px1=$_POST['x1'];
$py1=$_POST['y1'];
$px2=$_POST['x2'];
$py2=$_POST['y2'];
$amount_to_be_paid=$_POST['amount'];
if($x1>=$px1 && $x2<=$px2 && $y1>=$py1 && $y2<=$py2) { $check=-1; break; }
if($x1<=$px1 && $x2>=$px2 && $y1<=$py1 && $y2>=$py2) { $check=-2; break; }
//if(!check_intersection($x1,$y1,$x2,$y2,$px1,$py1,$px2,$py2)) { $check=-3; break; }
if(!check_intersection($x1,$y1,$x2,$y2,$px2,$py1,$px2,$py2)) { $check=-4; break; }
if(!check_intersection($x1,$y1,$x2,$y2,$px1,$py2,$px2,$py2)) { $check=-5; break; }
if(!check_intersection($x1,$y1,$x2,$y2,$px1,$py1,$px1,$py2)) { $check=-6; break; }
//if(!check_intersection($x2,$y1,$x2,$y2,$px2,$py1,$px2,$py2)) { $check=-7; break; }
if(!check_intersection($x2,$y1,$x2,$y2,$px1,$py2,$px2,$py2)) { $check=-8; break; }
if(!check_intersection($x2,$y1,$x2,$y2,$px1,$py1,$px1,$py2)) { $check=-9; break; }
//if(!check_intersection($x1,$y2,$x2,$y2,$px1,$py2,$px2,$py1)) { $check=-10; break; }
if(!check_intersection($x1,$y2,$x2,$y2,$px1,$py1,$px1,$py2)) { $check=-11; break; }
//if(!check_intersection($x1,$y1,$x1,$y2,$px1,$py1,$px1,$py2)) { $check=-12; break; }
}
}
// If Free Position found
if($check>0)
{
$fileName = $_FILES['userfile']['name'];
$tmpName = $_FILES['userfile']['tmp_name'];
$fileSize = $_FILES['userfile']['size'];
$fileType = $_FILES['userfile']['type'];
//------------------------------------------------//
//------------------------------------------------//
$fp = fopen($tmpName, 'r');
$content = fread($fp, filesize($tmpName));
$content = addslashes($content);
fclose($fp);
if(!get_magic_quotes_gpc())
{
$fileName = addslashes($fileName);
}
$x1=$_POST['x1'];
$y1=$_POST['y1'];
$x2=$_POST['x2'];
$y2=$_POST['y2'];
$url=$_POST['url'];
$title=$_POST['title'];
$name=$_POST['name'];
$email=$_POST['email'];
$amount=$_POST['amount'];
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((int)$usec + (int)$sec);
}
$time_start = microtime_float();
$id = $time_start;
/*
$query = "INSERT INTO area(id,x1,y1,x2,y2,url,title,name,email,amount,img_name,img_type,img_filesize, img_content,cnf_check) ".
"VALUES ('$id',$x1,$y1,$x2,$y2,'$url','$title', '$name','$email','$amount','$fileName','$fileType','$fileSize','',2)";
echo "Q: " . $query;
*/
$query = "INSERT INTO area
( x1
, y1
, x2
, y2
, url
, title
, name
, email
, amount
, cnf\_check
, image\_id
, img\_name
, img\_type
, img\_filesize
, img\_content
, paypal\_txn\_id
, clicks
)
VALUES ($x1,$y1,$x2,$y2,'$url', '$title', '$name','$email', '$amount', '2', '', '$fileName', '$fileType', '$fileSize', '', '', '0')";
if($link=mysql_query($query,$cn) or die(mysql_error()))
{
$id = mysql_insert_id($cn);
$msg1 = "Inserted!";
setcookie("id","$id");
if(is_uploaded_file($_FILES['userfile']['tmp_name'])){
$ext = explode("." , $_FILES['userfile']['name']);
//print_r($ext);
move_uploaded_file($_FILES['userfile']['tmp_name'] , "upload_img/" . $id . "." . $ext[1]);
}
}
else
{
echo "MySql Error";
echo mysql_error();
}
}
?><?php include "header.php"; ?><head><LINK href="images/style.css" type=text/css rel=stylesheet>
<style>
body {
background: url(images/pagebgnew.jpg) repeat;
}
.white
{
font-family: Verdana;
font-size: 11px;
font-weight: bold;
color: #FFFFFF;
}
.white_every
{
font-family: Verdana;
font-size: 11px;
color: #FFFFFF;
}
a
{
text-decoration: none;
}
.black
{
font-family: Verdana;
font-size: 11px;
font-weight: bold;
color: #000000;
}
.black_no_bold
{
font-family: Verdana;
font-size: 11px;
color: #000000;
}
#grid {
position: relative;
top: 0;
left: 0;
width: 1000;
height: 1000;
border: 0;
margin-left: auto;
margin-right: auto;
text-align: center;
background-image: url(images/grid.gif);
background-repeat: repeat;
}
.g {
position: absolute;
border: 0;
z-index: 3;
align: center;
}
</style>
<style>
a:hover{color:red}
</style>
</head>
<table width="1000" border=0 align="center" cellpadding=5 cellspacing=0>
<tr>
<td width=150 background="images/grid.gif"></td>
<td width=600 bgcolor=#CCCCCC>
<?php
$amount=$_POST['amount'];
$width=$_POST['width'];
$height=$_POST['height'];
$item_num="$width"."&"."$height";
?>
<?php
Hello,
*ups*
Eigentlich müsste man Dir als Antwort ca. 300 Seiten aus den Handbüchern von PHP und MySQL posten und dazu schreiben: guck mal, Dein Fehler ist da irgendwo genau beschrieben worden...
Aber erstens wäre das gemein und zweitens würde es das Forum sprengen.
Aber wie kann man Deinen Fehler nun lokalisieren?
Was war denn die letzte funktionstüchtige Version Deines Scriptes?
Was hast Du danach verändert?
Hast Du die SQL-Statements mal in einem funktionstüchtigen Frontend getestet, bevor Du Sie in PHP eingebaut hast?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Sorry,
aber nen längeres und unübersichtlicheres Stück Code konntest du wirklich nicht posten? Der Fehler wird ja eindeutig durch einen MYSQL Querry ausgelöst. Warum postest du nicht nur diesen?
Gruß
Markus
Hallo H-D Just
ich bekomme immer diese Fehlermeldung:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ','http://gojust.de', 'GoJust', 'Hans-Dieter Just','info@gojust.de', '', '2', '',' at line 3
Dass es nicht besonders toll ist, hier tonnenweise unrelevanten, noch dazu unformatierten Code zu schreiben, haben dir ja schon andere angekreidet (kann mir aber den nochmaligen Hinweis nicht verkneifen)
Zum eigentlichen Problem:
Der Fehler scheint ja in diesem Ausschnitt zu liegen (zumindest, wenn ich da jetzt richtig durchblicke):
/*
$query = "INSERT INTO area(id,x1,y1,x2,y2,url,title,name,email,amount,img_name,img_type,img_filesize, img_content,cnf_check) ".
"VALUES ('$id',$x1,$y1,$x2,$y2,'$url','$title', '$name','$email','$amount','$fileName','$fileType','$fileSize','',2)";
echo "Q: " . $query;
*/
$query = "INSERT INTO
area
(x1
,y1
,x2
,y2
,url
,title
,name
,amount
,cnf\_check
,image\_id
,img\_name
,img\_type
,img\_filesize
,img\_content
,paypal\_txn\_id
,clicks
)VALUES ($x1,$y1,$x2,$y2,'$url', '$title', '$name','$email', '$amount', '2', '', '$fileName', '$fileType', '$fileSize', '', '', '0')";
Es wäre sinnvoll, sich den genauen Querystring nochmals ausgeben zu lassen (wie du es ja in dem auskommentierten Stück oben getan hast), also etwa so:
$query = "INSERT INTO `area` ( `x1` , `y1` , `x2` , `y2` , `url` , `title` , `name` , `email` , `amount` , `cnf_check` , `image_id` , `img_name` , `img_type` , `img_filesize` , `img_content` , `paypal_txn_id` , `clicks` )
VALUES ($x1,$y1,$x2,$y2,'$url', '$title', '$name','$email', '$amount', '2', '', '$fileName', '$fileType', '$fileSize', '', '', '0')";
echo $query."<br />";
Wie du Code hier im Forum formatieren kannst steht übrigens in der Hilfe zum Forum
Zur Ursache kann ich jetzt erstmal nur raten, mir ist aber aufgefallen, dass du jede Menge Variablen ungeprüft in die Ausgabe einbaust, was eventuell für den Fehler verantwortlich ist - falls die Daten entsprechend "bösartig" sind - aber auch ansonsten auf jeden Fall ein Sicherheitsrisiko darstellt. mysql_real_escape_string() ist dein Freund.
Außerdem fügst du die Variablen $x1,$y1,$x2,$y2 ohne Anführungszeichen ein, was nur korrekt ist, falls es sich um nummerische Felder handelt, was ebenfalls geprüft werden müßte.
Im Gegensatz dazu fügst du hinten '2' und '0' ein, wo die Anführungszeichen - wahrscheinlich - unnötig sind, falls es sich nicht um Felder vom Typ VARCHAR, CHAR oder TEXT handelt. Wenn du wirklich '2' und nicht 2 einfügen möchtest und weißt, was du tust, vergiss diese Anmerkung und entschuldige die Kritik.
Liebe Grüße mbr
Moin!
Außerdem fügst du die Variablen $x1,$y1,$x2,$y2 ohne Anführungszeichen ein, was nur korrekt ist, falls es sich um nummerische Felder handelt, was ebenfalls geprüft werden müßte.
Ich wiederhole mich gerne ganz deutlich: Der Verzicht auf die einfachen Anführungszeichen um Felder, die numerischen Inhalt haben, ist in SQL (mindestens MySQL) nicht hilfreich bis schädlich. Man sollte grundsätzlich ALLE Felder in Anführungszeichen setzen und dann ebenso grundsätzlich escapen. Die Datenbank erhält, egal ob mit oder ohne Anführungszeichen, sowieso einen String mit dem Zahlenwert, der wieder zu parsen und zu verstehen ist, sofern das Ziel ein Feld mit Zahlentyp ist.
Anführungszeichen sind wirklich nur dann entbehrlich, wenn die Zahl als konstanter Text im Query steht, somit garantiert nicht "aus Versehen" plötzlich Text enthält (der zu escapen wäre, was nur innerhalb von Anführungszeichen gültiges SQL ergibt), oder wenn mathematische Rechnungen durchzuführen sind.
Im Gegensatz dazu fügst du hinten '2' und '0' ein, wo die Anführungszeichen - wahrscheinlich - unnötig sind, falls es sich nicht um Felder vom Typ VARCHAR, CHAR oder TEXT handelt. Wenn du wirklich '2' und nicht 2 einfügen möchtest und weißt, was du tust, vergiss diese Anmerkung und entschuldige die Kritik.
MySQL wandelt für Textfelder eine 2 in eine '2' und für Zahlenfelder eine '2' in eine 2. Der Arbeitsaufwand ist dabei in jedem Fall der gleiche, da beide Darstellungen im Query Strings sind, die man parsen muß.
- Sven Rautenberg
Hello,
Ich wiederhole mich gerne ganz deutlich: Der Verzicht auf die einfachen Anführungszeichen um Felder, die numerischen Inhalt haben, ist in SQL (mindestens MySQL) nicht hilfreich bis schädlich. Man sollte grundsätzlich ALLE Felder in Anführungszeichen setzen und dann ebenso grundsätzlich escapen. Die Datenbank erhält, egal ob mit oder ohne Anführungszeichen, sowieso einen String mit dem Zahlenwert, der wieder zu parsen und zu verstehen ist, sofern das Ziel ein Feld mit Zahlentyp ist.
und ich wiederhole mich auch gerne deutlich: das sollte man bei DB2 5 und 6 nicht tun, da die DB2 einem das dann gerne mit einem Type Mismatch um die Ohren haut...(möglicherweise abhängig von der Konfiguration)
MfG
Rouven
Moin!
Ich wiederhole mich gerne ganz deutlich: Der Verzicht auf die einfachen Anführungszeichen um Felder, die numerischen Inhalt haben, ist in SQL (mindestens MySQL) nicht hilfreich bis schädlich. Man sollte grundsätzlich ALLE Felder in Anführungszeichen setzen und dann ebenso grundsätzlich escapen. Die Datenbank erhält, egal ob mit oder ohne Anführungszeichen, sowieso einen String mit dem Zahlenwert, der wieder zu parsen und zu verstehen ist, sofern das Ziel ein Feld mit Zahlentyp ist.
und ich wiederhole mich auch gerne deutlich: das sollte man bei DB2 5 und 6 nicht tun, da die DB2 einem das dann gerne mit einem Type Mismatch um die Ohren haut...(möglicherweise abhängig von der Konfiguration)
Ich schätze, der einzige sinnvolle Ausweg aus der Misere ist, "prepared statements" zu nutzen - eine Methode, die in PHP mit MySQL nur durch das mysqli-Interface möglich ist.
Aber da man sowieso kein PHP 4 mehr benutzen sollte (es sind wahrscheinlich diverse Sicherheitsbugs auch in der aktuellsten 4er-Version, die Entwickler haben nur keine Lust mehr, die Fixes aus der aktuellen 5 nochmal zurückzuportieren - irgendwie verständlich), dürfte die Verfügbarkeit von mysqli kein grundsätzliches Problem sein.
- Sven Rautenberg
Hello,
Ich wiederhole mich gerne ganz deutlich: Der Verzicht auf die einfachen Anführungszeichen um Felder, die numerischen Inhalt haben, ist in SQL (mindestens MySQL) nicht hilfreich bis schädlich. Man sollte grundsätzlich ALLE Felder in Anführungszeichen setzen und dann ebenso grundsätzlich escapen. Die Datenbank erhält, egal ob mit oder ohne Anführungszeichen, sowieso einen String mit dem Zahlenwert, der wieder zu parsen und zu verstehen ist, sofern das Ziel ein Feld mit Zahlentyp ist.
Dem widerspreche ich.
ALLE werte kann man nicht in Anführungszeichen setzen.
So sind NULL, TRUE und FALSE davon auszunehmen.
Diese reservierten Wörter müssen OHNE Häkchen übergeben werden. Wer also mit dem Spaltentyp Binaray arbeiten will, muss dies beachten und wer Felder bewußt "zurücksetzen" will auf NULL eben auch.
Man kann die Schnittstelle aber trotzdem automatisieren, da die Datenbank ihre Spaltentypen ja kennt und man diese also vorher mit den vom Client kommenden Werten abgleichen kann.
Da man NULL, TRUE und FALSE vermutlich nicht als reservierte Wörter vom Client bezieht, sondern irgendwie als Checkbox, Radio oder Select-Value sollte es also keine Probleme bereiten, diese einzusetzen.
Man kann aber eben nicht mit dem "großen Hammer" über sein assoziatives Datenarray flitzen, um die Werte darin in Häkchen zu escapen und in Häkchen zu setzen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hello,
Man kann aber eben nicht mit dem "großen Hammer" über sein assoziatives Datenarray flitzen, um die Werte darin zu escapen und in Häkchen zu setzen.
Sollte so herum heißen, weil erst escaped werden muss und DANN erst in Häkchen gesetzt werden kann.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hello,
Hello,
Ich wiederhole mich gerne ganz deutlich: Der Verzicht auf die einfachen Anführungszeichen um Felder, die numerischen Inhalt haben, ist in SQL (mindestens MySQL) nicht hilfreich bis schädlich. Man sollte grundsätzlich ALLE Felder in Anführungszeichen setzen und dann ebenso grundsätzlich escapen. Die Datenbank erhält, egal ob mit oder ohne Anführungszeichen, sowieso einen String mit dem Zahlenwert, der wieder zu parsen und zu verstehen ist, sofern das Ziel ein Feld mit Zahlentyp ist.
Dem widerspreche ich.
ALLE werte kann man nicht in Anführungszeichen setzen.
NULL
Dieses reservierte Wort muss OHNE Häkchen übergeben werden.
Wer also Felder bewußt "zurücksetzen" will, mus NULL übergeben können und nicht 'NULL'.
Das mit "Binary" war natürlich Quatsch.
Sollte ohnehin Boolean heißen, aber den Spaltentyp gibt's bei MySQL nicht. Kommt also nur bei anderen DBMS zum Tgragen.
Enum erfordert allerdings Strings in Häkchen.
True und false kommen dann nur als Vergleichswerte in Frage, lassen sich aber auch prima in "Binaray(1)" eintragen *duck*
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hi,
Sollte ohnehin Boolean heißen, aber den Spaltentyp gibt's bei MySQL nicht.
Gruß,
Andreas.
Hello,
Sollte ohnehin Boolean heißen, aber den Spaltentyp gibt's bei MySQL nicht.
Tinyint nimmt aber auch andere Werte als 0 oder 1 an.
http://dev.mysql.com/doc/refman/5.0/en/other-vendor-data-types.html
Dass es die Konstanten True und False gibt, ist klar. Deshalb war ich ja drauf gekommen, dass man nicht rigoros alle übergebenen Werte escpapen und in Häkchen einpacken darf.
Wenn Du dem Tinyint, der Dein Boolean repräsentieren sollst "true" übergibst (also in Häkchen), macht er natürlich trotzdem 0 entsprechend false daraus.
Das war das, was ich vorhin im Auge hatte.
Es findet keine vollständige Typkontrolle statt, sondern es wird eben umgewandelt, was das Zeug hält.
Aber einen echten Boolean-Spaltentyp gibt es bei MySQL deshalb trotzdem nicht. Das wollte ich nur richtigstellen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom