[MySQL 4.0] Problem mit UPDATE-Query

[Yadgar]

Hi(gh)!

Wenn ich mit PHP diese Query hier formatiere:

$query = "UPDATE hersteller SET Firmenname='".mysql_real_escape_string($Firmenname)."', Land='".mysql_real_escape_string($Land)."', Status='".mysql_real_escape_string($Status)."', Link='".mysql_real_escape_string($Link)."' WHERE ID=".$entry;

schmeißt MySQL regelmäßig diese Fehlermeldung:

1064: 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 '' at line 1

Ich bin, aus welchem Grund auch immer, leider nicht in der Lage, mir den Query-String anzeigen zu lassen... was läuft hier falsch?

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

Ich bin, aus welchem Grund auch immer, leider nicht in der Lage, mir den Query-String anzeigen zu lassen... was läuft hier falsch?

Zu wenig Phantasie?

Wenn man einen String in einer Variable hat, dann wird sich immer ein Weg finden, den anzuzeigen oder aber in eine Datei zu schreiben und sich diese später anzusehen.

$query = "UPDATE hersteller  
SET  
   Firmenname='".mysql_real_escape_string($Firmenname)."',  
   Land='".mysql_real_escape_string($Land)."',  
   Status='".mysql_real_escape_string($Status)."',  
   Link='".mysql_real_escape_string($Link)."'  
WHERE ID=".$entry;

So gibt es später eine Fehlermeldung mit brauchbarer Zeilennummer.

Jörg Reinholz

[Yadgar]

Hi(gh)!

So gibt es später eine Fehlermeldung mit brauchbarer Zeilennummer.

Es ist kein PHP-, sondern ein MySQL-Error, die Zeilennummer wird immer 1 sein!

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

Es ist kein PHP-, sondern ein MySQL-Error, die Zeilennummer wird immer 1 sein!

Nein!

Jörg Reinholz

[Jörg Reinholz]

Es ist kein PHP-, sondern ein MySQL-Error, die Zeilennummer wird immer 1 sein!

Nein!

genauer:

SQL:  
            UPDATE hersteller  
            SET Firmenname='foo\' GmbH',  
            Land='DE',  
            Status='1',  
            Link='viel text'  
            WHERE ID=  

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 '' at line 6

Jörg Reinholz

[M.]

Mahlzeit,

Ich bin, aus welchem Grund auch immer, leider nicht in der Lage, mir den Query-String anzeigen zu lassen...

Also schaffst du kein echo $query; oder, falls es weder im Browser noch in der Kommandozeile läuft, ein error_log($query);?
Ich bezweifel, dass du dann mit Datenbanken spielen solltest.

Was aber noch spannend ist, wieso du ein DBMS aus der Steinzeit nutzen willst. Wieso kein Mysql 5?

[Yadgar]

Hi(gh)!

Mahlzeit,

Ich bin, aus welchem Grund auch immer, leider nicht in der Lage, mir den Query-String anzeigen zu lassen...

Also schaffst du kein echo $query; oder, falls es weder im Browser noch in der Kommandozeile läuft, ein error_log($query);?

Weder noch!

Ich bezweifel, dass du dann mit Datenbanken spielen solltest.

Womit denn sonst? Mit Playmobil? Oder besser gleich wie all die anderen Loser, die mit zweistelligem IQ durch den Alltag stolpern, mit dem Saufen anfangen und beizeiten sozialverträglich frühableben?

Nein, ernsthaft: ich finde es ungemein motivierend, wie ihr keeeeewlen Nerds Leute runtermacht, die nicht so keeeeewl sind wie ihr...

Zurück zu meinem Problem:

Falls die Seite mit dem Edit-Flag (vorhandene Datensätze ändern) aufgerufen wurde:

else if ($_GET['edit']=="yes")  
{  
  echo "Hallo!";  
  input();  
}  

wird die Funktion input() aufgerufen, die das Eingabeformular erzeugt, und zwar abhängig von den aktuellen GET-Variablen mit unterschiedlicher action-Adresse:

if ($_GET['edit']=="yes")  
{  
  $entry = $_GET['entry'];  
  dbcall();  
  $query = "SELECT * FROM hersteller WHERE ID=".$entry;  
  // echo '<p>'.$query.'</p>';  
  $result = mysql_query($query);  
  dberror();  
  $row = mysql_fetch_row($result);  
  $formtop = '<form method="POST" action="hersteller.php?section=2&first=0&edit=yes">';  
}  
else  
{  
  // $s = 1;  
  $formtop = '<form method="POST" action="hersteller.php?section=1&first=0">';  
}  
echo '<p>'.$s.'</p>';  
echo $formtop;  
  
[...]  
  

Nachdem die Daten abgeschickt sind, verzweigt die Funktion bei edit=yes zum UPDATE-Query:

      if (!$Firmenname)  
      {  
	echo "Sie haben keine Daten eingegeben!<br>";  
      }  
      else  
      {  
	dbcall();  
        switch ($_GET['section'])  
        {  
          case 1:  
	    $query = "INSERT INTO hersteller (Firmenname, Land, Status, Link) VALUES ('".mysql_real_escape_string($Firmenname)."','".mysql_real_escape_string($Land)."','".mysql_real_escape_string($Status)."','".mysql_real_escape_string($Link)."')";  
	  break;  
	  case 2:  
	    $query = "UPDATE hersteller SET Firmenname='".mysql_real_escape_string($Firmenname)."', Land='".mysql_real_escape_string($Land)."', Status='".mysql_real_escape_string($Status)."', Link='".mysql_real_escape_string($Link)."' WHERE ID=".$entry;  
	    error_log($query);  
	  break;  
	}  
	  
	$result = mysql_query($query);  
	dberror();  
	echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";  
	$db = mysql_close();  
	dberror();  
      }  

Durch sukzessives Auskommentieren habe ich herausgefunden, dass der Fehler im case 2-Block liegt (der Querystring in case 1 wird korrekt verarbeitet)... und error_log($query) wird erst gar nicht ausgeführt, weil das Programm schon vorher abbricht...

Was aber noch spannend ist, wieso du ein DBMS aus der Steinzeit nutzen willst. Wieso kein Mysql 5?

Weil auf dem Server nichts anderes läuft!

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

und error_log($query) wird erst gar nicht ausgeführt, weil das Programm schon vorher abbricht...

Wie wäre es denn damit die $query _vorher_ zu loggen?

Den Rest ignoriere ich. Teils aus Höflichkeit, in jedem Fall, weil er sachlich nichts bringt.

Jörg Reinholz

[Yadgar]

Hi(gh)!

Wie wäre es denn damit die $query _vorher_ zu loggen?

Vorher? Bevor der String überhaupt zugewiesen wurde? Was soll denn das?

Bis bald im Khyberspace!

Yadgar

[1UnitedPower]

Meine Herren!

Wie wäre es denn damit die $query _vorher_ zu loggen?

Vorher? Bevor der String überhaupt zugewiesen wurde? Was soll denn das?

Nach dem Zusammengefrickel und bevor du die Anfrage an die Datenbank stellst sollte es ein Zeitfenster geben, das du nutzen kannst um den Query-String zu untersuchen. Wenn du an dieser Stelle keine Ausgabe vornehmen kannst, dann kannst du, wie schon vorgeschlagen, den Anfragetext auch in einer Datei loggen: file_put_contents() ist dein Freund.

[Yadgar]

Hi(gh)!

Nach dem Zusammengefrickel und bevor du die Anfrage an die Datenbank stellst sollte es ein Zeitfenster geben, das du nutzen kannst um den Query-String zu untersuchen. Wenn du an dieser Stelle keine Ausgabe vornehmen kannst, dann kannst du, wie schon vorgeschlagen, den Anfragetext auch in einer Datei loggen: file_put_contents() ist dein Freund.

  case 2:  
    $query = "UPDATE hersteller SET Firmenname='".mysql\_real\_escape\_string($Firmenname)."', Land='".mysql\_real\_escape\_string($Land)."', Status='".mysql\_real\_escape\_string($Status)."', Link='".mysql\_real\_escape\_string($Link)."' WHERE ID=".$entry;  
    file\_put\_contents(errorlog, $query);  
  break;  

funktioniert auch nicht! Es wird erst gar keine Textdatei "errorlog" erzeugt!

Bin ich zu dumm für PHP?

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

file_put_contents(errorlog, $query);
  break;

funktioniert auch nicht! Es wird erst gar keine Textdatei "errorlog" erzeugt!

Mach eine Pause. Die Sache macht Dich offenbar nervös und Du baust neue Fehler ein.

Es müsste nämlich:

file_put_contents('errorlog', $query);

lauten, denn die Konstante errorlog hast Du sicherlich nicht belegt.

Jörg Reinholz

[1UnitedPower]

Meine Herren!

Es müsste nämlich:

file_put_contents('errorlog', $query);

lauten, denn die Konstante errorlog hast Du sicherlich nicht belegt.

Was dazu führt, dass PHP eigenmächtig eine Konstante errorlog mit dem Wert 'errorlog' anlegt, das führt nur zu einer E_NOTICE. Der Code sollte daran also nicht scheitern. Das ist ein richtig dummer Bug… errr… Feature! von PHP.

[Jörg Reinholz]

Und übrigens: Das hier zu lesen und anzuwenden hätte auch geholfen.

Vergiss meine die andere Antwort nicht und mach einfach die Pause. Es ist meine langjährige Erfahrung, dass man bei "verzwickten" Fehlern nach einer gewissen Zeit der Fehlersuche besser radikal abbricht und eine Stunde lang "den Scheiß nicht mehr ansieht".

Alles andere dauert (sehr viel) länger.

Jörg Reinholz

[Yadgar]

Mach eine Pause. Die Sache macht Dich offenbar nervös und Du baust neue Fehler ein.

Dann sollte ich wahrscheinlich das Projekt ganz aufgeben und akzeptieren, dass ich zum Programmieren schlicht zu dumm bin!

file_put_contents('errorlog', $query);

Funktioniert AUCH NICHT!

Wo geht die nächste Zeitmaschine nach [ZENSIERT], damit ich endlich meinem wohlverdienten [ZENSIERT]tod zugeführt werde?

ICH KANN NICHT MEHR!!!

[Jörg Reinholz]

Dann sollte ich wahrscheinlich das Projekt ganz aufgeben und akzeptieren, dass ich zum Programmieren schlicht zu dumm bin!

Das hat mit Dummheit nichts zu tun, sondern damit, was unser Gehirn mit uns anstellt. Das sich jemand selbst verrückt macht ist der Normalzustand, keine Ausnahme.

Teste (wenn nicht schon vorhanden) vor allem abends auch mal eine dieser billigen Lesebrillen mit +1 Dioptrien aus dem Lebensmitteleinzelhandel. (Die kann man spätestens beim Löten oder Basteln als "Lupe" nehmen).

Funktioniert AUCH NICHT!

Mach Pause. Geh kac... in die Wanne oder am besten einfach mal raus. Esse etwas. Meide Kaffee. Mein Geheimtipp: Malzbier. Wenn der Chef meckert sag ihm, dass es mit Pause schneller und billiger wird.

Wenn Du dann weiter machst, dann schalte das Error-Reporting auf "Full-Speed" (error_reporting(E_ALL) oder nimm gleich meinen use-strict-Hammer.

Jörg Reinholz

[Auge]

Hallo

file_put_contents('errorlog', $query);

Funktioniert AUCH NICHT!

In welchen Verzeichnissen suchst du nach der Daten namens „errorlog“? Hast du bei deinen Tests dafür gesorgt, dass case „2“ ist, damit dieser Zweig mit dem file_put_contents zur Ausführung kommt? Nicht, dass nichts passiert, weil nichts passiert!

Um den Query während der Tests in jedem Fall zu erwischen, würde ich den Aufruf von file_put_contents hinter den case-Block setzen. Alternativ kannst du eine Ausgabe im Browser erzwingen. Das kannst du mit echo "<pre>".print_r($query, true)."</pre>"; an gleicher Stelle erreichen.

  dbcall();  
  switch ($_GET['section'])  
    {  
    case 1:  
      $query = "INSERT INTO hersteller (Firmenname, Land, Status, Link) VALUES ('".mysql_real_escape_string($Firmenname)."','".mysql_real_escape_string($Land)."','".mysql_real_escape_string($Status)."','".mysql_real_escape_string($Link)."')";  
    break;  
    case 2:  
      $query = "UPDATE hersteller SET  
Firmenname='".mysql_real_escape_string($Firmenname)."',  
Land='".mysql_real_escape_string($Land)."',  
Status='".mysql_real_escape_string($Status)."',  
Link='".mysql_real_escape_string($Link)."'  
WHERE ID=".$entry;  
    break;  
    }  
  file_put_contents('errorlog', $query);  
  echo "<pre>".print_r($query, true)."</pre>";  // alternative oder zusätzliche Anzeige am Bildschirm  
  $result = mysql_query($query);

Und zu guter Letzt und voraussehbar: deine Umschalttaste klemmt gelegentlich. ;-)

Tschö, Auge

[Jörg Reinholz]

Und zu guter Letzt und voraussehbar: deine Umschalttaste klemmt gelegentlich. ;-)

Der TO ist schon mit den Nerven am Ende. Da ist man nahe am Authismus.

Also sagen wir ihm doch besser, dass wir vermuten, dass

WHERE ID=".$entry;

Vielleicht

WHERE ID=".$Entry

heißen soll (die anderen Variablen beginnen auch groß und genau das könnte zum bestens mysql-syntax-error passen).

Allerdings wäre das nur die Hilfe für diesen einen Fehler, der sich dann beliebig wiederholen kann ohne dass der TO ein Hilfsmittel hat, diese zu erkennen.

Jörg Reinholz

[Auge]

Hallo

Und zu guter Letzt und voraussehbar: deine Umschalttaste klemmt gelegentlich. ;-)

Der TO ist schon mit den Nerven am Ende. Da ist man nahe am Authismus.

Deshalb ja der Smiley. Aber ja, der kann auch falsch ankommen.

Also sagen wir ihm doch besser, dass wir vermuten, dass

WHERE ID=".$entry;

Vielleicht

WHERE ID=".$Entry

heißen soll (die anderen Variablen beginnen auch groß und genau das könnte zum bestens mysql-syntax-error passen).

Oder die Variable, heiße sie nun $entry oder $Entry, ist nicht vorhanden oder unbefüllt, so dass WHERE ID= herauskommt.

Allerdings wäre das nur die Hilfe für diesen einen Fehler, der sich dann beliebig wiederholen kann ohne dass der TO ein Hilfsmittel hat, diese zu erkennen.

Was er machen kann, hast du ja nun lang und breit erklärt. Wie er aus der Falle, dass irgendwas nicht will und er nicht sieht, was es ist, rauskommen kann, auch. Nämlich *ausgiebig* pausieren und den Kopf frei kriegen. Das Wetter ist zumindest hier viel zu schön zum am-Rechner-hocken.

Tschö, Auge

[ChrisB]

Hi,

Oder die Variable, heiße sie nun $entry oder $Entry, ist nicht vorhanden oder unbefüllt, so dass WHERE ID= herauskommt.

Ich vermute ja eher, dass $query „leer“ ist – das würde „ich kann ihren Inhalt nicht ausgeben“ und auch den MySQL-Fehler besser erklären.

MfG ChrisB

[Yadgar]

Hi(gh)!

Oder die Variable, heiße sie nun $entry oder $Entry, ist nicht vorhanden oder unbefüllt, so dass WHERE ID= herauskommt.

Das war der Grund! Ich habe die echo-Zeile mit dem Formularkopf so ergänzt, dass $_GET['entry'] mit übernommen wird - und seither habe ich die Fehlermeldung nicht mehr!

Allerdings... eine Datenbankoperation findet trotzdem nicht statt, auch nach Eingabe neuer Daten ins Eingabeformular! Und das Verstörendste: es ist nach wie vor nicht möglich, den Query-String anzuzeigen!

  
      else  
      {  
	dbcall();  
        switch ($_GET['section'])  
        {  
          case 1:  
	    $query = "INSERT INTO hersteller (Firmenname, Land, Status, Link) VALUES ('".mysql_real_escape_string($Firmenname)."','".mysql_real_escape_string($Land)."','".mysql_real_escape_string($Status)."','".mysql_real_escape_string($Link)."')";  
	  break;  
	  case 2:  
	    $query = "UPDATE hersteller SET Firmenname='".mysql_real_escape_string($Firmenname)."', Land='".mysql_real_escape_string($Land)."', Status='".mysql_real_escape_string($Status)."', Link='".mysql_real_escape_string($Link)."' WHERE ID=".$entry;  
	    file_put_contents('errorlog', $query);  
	  break;  
	  default:  
	    echo "<p>section = ".$_GET['section']."</p>";  
	}  
	echo "<p>Query = ".$query."</p>";  
	// error_log("\n".$query, 3, "query.log");  
	$result = mysql_query($query);  
	dberror();  
	echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";  
	$db = mysql_close();  
	dberror();  
      } 

Es wird anscheinend weder case 2 noch default angelaufen! Und ich bekomme nach dem switch-Block rein gar keine Textausgabe, nicht einmal "Query = "! ICH VERSTEHE DAS ALLES NICHT!!!

Was er machen kann, hast du ja nun lang und breit erklärt. Wie er aus der Falle, dass irgendwas nicht will und er nicht sieht, was es ist, rauskommen kann, auch. Nämlich *ausgiebig* pausieren und den Kopf frei kriegen.

Funktioniert auch nicht, sobald ich mich wieder mit dem Problem befasse, ist der Kopf in kürzester Zeit wieder "dicht" und ich kann gleich die nächste Pause machen - so wird das NIE was!

Das Wetter ist zumindest hier viel zu schön zum am-Rechner-hocken.

...und vernünftig arbeiten geht hier auch nicht, ständig plärrt von draußen das Geschrei verhaltensgestörter Türkenbälger rein, es ist zum Davonlaufen! Scheiß Prollviertel!!!

Bis bald im Khyberspace!

Yadgar

[Auge]

Hallo

Oder die Variable, heiße sie nun $entry oder $Entry, ist nicht vorhanden oder unbefüllt, so dass WHERE ID= herauskommt.

Das war der Grund! Ich habe die echo-Zeile mit dem Formularkopf so ergänzt, dass $_GET['entry'] mit übernommen wird - und seither habe ich die Fehlermeldung nicht mehr!

Allerdings... eine Datenbankoperation findet trotzdem nicht statt, auch nach Eingabe neuer Daten ins Eingabeformular! Und das Verstörendste: es ist nach wie vor nicht möglich, den Query-String anzuzeigen!

Ok, gibt es 'section' als URL-Parameter und wenn ja, was steht da drin?

Zudem, PHP nutzt ja automatische Typkonvertierung, dein Code sollte an der Stelle funktionieren. Dennoch als Anmerkung, damit es im Hinterkopf bleibt: $_GET['section'] ist per se vom Typ String, im Switch-Block prüfst du jedoch auf Integer-Werte.

Tschö, Auge

[Yadgar]

Hi(gh)!

Ok, gibt es 'section' als URL-Parameter und wenn ja, was steht da drin?

Kann ich leider überhaupt nicht sagen - ich kann nicht mehr auf meine Seiten zugreifen, bekomme immer nur "403 Forbidden"!

Ich glaube, ich gebe die Idee mit dem Datenbankprojekt besser auf... das scheint etliche Nummern zu groß für mich zu sein!

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

Oder die Variable, heiße sie nun $entry oder $Entry, ist nicht vorhanden oder unbefüllt, so dass WHERE ID= herauskommt.

Das war der Grund! Ich habe die echo-Zeile mit dem Formularkopf so ergänzt, dass $_GET['entry'] mit übernommen wird - und seither habe ich die Fehlermeldung nicht mehr!

Aha... Du hast uralte Skriptsbeispiele abgeschrieben. Schmeiß das Buch weg, denn die Formulardaten werden schon seit vielen Jahren nicht mehr direkt in Variablen übernommen. $_GET, $_POST, in Ausnahmefällen $_REQUEST sind Deine Freunde.

Was ist mit Firmenname, ID, Land und so weiter? Und was machst Du an der Stelle, wo Du $query zusammenstöpselst?

Allerdings... eine Datenbankoperation findet trotzdem nicht statt, auch nach Eingabe neuer Daten ins Eingabeformular!

Aus Deinem "Skript": $result = mysql_query($query);

Hier machst Du was falsch. Du fängst den möglichen Fehler nicht ab. In der Dokumentation von php.net steht unter mysql_error wie das geht.

Und das Verstörendste: es ist nach wie vor nicht möglich, den Query-String anzuzeigen!

Dann machst Du was falsch, weil Du offenbar nicht genügend Kenntnisse über das konkrete System, für welches Du programmierst, hast. Kann es ein, dass Du noch nie in den Quelltext der resultierenden Webseite gesehen hast? Fehlermeldungen stehen oft ganz oben und werden eventuell von darüber gelegten Elementen verdeckt - bleiben im Quelltext aber sichtbar. Kann es ein, dass Fehlermeldungen und/oder Notizen nicht ausgegeben werden? Kann es ein, dass Du nicht ins richtige error-log schaust?

Wenn das hier folgende nicht funktioniert, dann ist Dir ohne Zugriff auf den Server nicht zu helfen:

Lege ein im Serverroot ein Verzeichnis "logs" an. Setze dessen Eigenschaften so, dass JEDER es betreten kann.

Lege darin eine Datei "logfile" an. Setze deren Eigenschaften so, dass JEDER (insbesondere der WEBSERVER!) diese lesen und schreiben kann. (Nicht: ausführen!)

Hole:
http://www.fastix.org/r/use_strict.txt und speichere diese als

use_strict.php

im Serverroot.

Stelle in die erste Zeile Deines Skriptes

<?php  
define('DEBUG', 2); require_once( $_SERVER['DOCUMENT_ROOT'] . '/use_strict.php' );

4.)
nimm
entweder 4a)

  
error_log($query, 3, $_SERVER['DOCUMENT_ROOT'] . '/logs/logfile]' );  

oder  4b)

  
file_put_contents( $_SERVER['DOCUMENT_ROOT' . '/logs/logfile]' ,$query,  FILE_APPEND );  

oder 4c)

  
trigger_error( $query, E_USER_ERROR );  

um $query angezeigt zu bekommen oder im Logfile stehen zu haben.

Ich bin mir sicher, dass ich das Problem mit Zugriff auf den Server in Nullkommanichts lösen könnte, so dass der größte Aufwand das Schreiben einer Rechnung über 60 Euro (netto) gewesen wäre.

Jörg Reinholz

[Yadgar]

Hi(gh)!

Aha... Du hast uralte Skriptsbeispiele abgeschrieben.

Nein, keine uralten Skriptbeispiele aus irgendwelchen uralten Büchern, das Skript ist komplett auf meinem Mist gewachsen. Und dass Formulardaten als Arrays unter $_GET bzw. $_POST übernommen werden (in dem Fall hier in $_GET) weiß ich auch nicht erst seit gestern...

Was ist mit Firmenname, ID, Land und so weiter? Und was machst Du an der Stelle, wo Du $query zusammenstöpselst?

Um mir Tipparbeit zu sparen, weise ich die doch etwas sperrigen Array-Elemente Variablen wie $Firmenname, $ID usw. zu.

Hier machst Du was falsch. Du fängst den möglichen Fehler nicht ab. In der Dokumentation von php.net steht unter mysql_error wie das geht.

Doch, mache ich sehr wohl, und zwar nach jeder Datenbankoperation:

	echo "<p>Query = ".$query."</p>";  
	$result = mysql_query($query);  
	dberror();  
	echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";  
	$db = mysql_close();  
	dberror();  

dberror() ist definiert wie folgt:

  function dberror()  
  {  
    if (mysql_errno())  
    {  
      switch(mysql_errno())  
      {  
	case 1062:  
	  die ("Ein Eintrag mit diesen Daten existiert bereits! Bitte korrigieren Sie Ihre Eingabe!<br>");  
	break;  
	default:  
	  die (mysql_errno().": ".mysql_error()."<br>");  
      }  
    }  
  }  

Und das Verstörendste: es ist nach wie vor nicht möglich, den Query-String anzuzeigen!

Dann machst Du was falsch, weil Du offenbar nicht genügend Kenntnisse über das konkrete System, für welches Du programmierst, hast. Kann es ein, dass Du noch nie in den Quelltext der resultierenden Webseite gesehen hast? Fehlermeldungen stehen oft ganz oben und werden eventuell von darüber gelegten Elementen verdeckt - bleiben im Quelltext aber sichtbar. Kann es ein, dass Fehlermeldungen und/oder Notizen nicht ausgegeben werden?

Nach dem (vermeintlichen) Absenden des ausgewählten und veränderten Datensatzes steht das hier im Browser (nachträglich von Hand formatiert - ich sollte das PHP-Skript besser so programmieren, dass es die Einrückungen des Codes selbst vornimmt!) - von Fehlermeldungen keine Spur!

Kann es ein, dass Du nicht ins richtige error-log schaust?

Keine Ahnung... woher weiß ich denn, wo und was das richtige error-log ist?

Wenn das hier folgende nicht funktioniert, dann ist Dir ohne Zugriff auf den Server nicht zu helfen:

Lege ein im Serverroot ein Verzeichnis "logs" an. Setze dessen Eigenschaften so, dass JEDER es betreten kann.

Ein solches Verzeichnis existiert bereits!

Lege darin eine Datei "logfile" an. Setze deren Eigenschaften so, dass JEDER (insbesondere der WEBSERVER!) diese lesen und schreiben kann. (Nicht: ausführen!)

Es existiert außerdem schon eine Datei names error_log... ich habe sie mir runtergeladen und festgestellt, dass dort tatsächlich die PHP-Fehler vom letzten Aufrufen der fraglichen Seite notiert wurden!

Für den Reload gerade eben habe ich folgende Meldungen, allesamt "nur" Warnungen, aber noch keine Fehler:

[Fri Sep 19 21:35:57 2014] [warn] [client 92.204.124.82] mod_fcgid: stderr: PHP Notice:  Undefined index: sort in /var/www/vhosts/rock-o-data.de/httpdocs/khyberspace/greenbook_admin/hersteller.php on line 188, referer: http://www.rock-o-data.de/khyberspace/greenbook_admin/hersteller.php?section=2&first=0&edit=yes&entry=3
[Fri Sep 19 21:35:57 2014] [warn] [client 92.204.124.82] mod_fcgid: stderr: PHP Notice:  Undefined index: sort in /var/www/vhosts/rock-o-data.de/httpdocs/khyberspace/greenbook_admin/hersteller.php on line 211, referer: http://www.rock-o-data.de/khyberspace/greenbook_admin/hersteller.php?section=2&first=0&edit=yes&entry=3
[Fri Sep 19 21:35:57 2014] [warn] [client 92.204.124.82] mod_fcgid: stderr: PHP Notice:  Undefined index: delete in /var/www/vhosts/rock-o-data.de/httpdocs/khyberspace/greenbook_admin/hersteller.php on line 230, referer: http://www.rock-o-data.de/khyberspace/greenbook_admin/hersteller.php?section=2&first=0&edit=yes&entry=3
[Fri Sep 19 21:35:57 2014] [warn] [client 92.204.124.82] mod_fcgid: stderr: PHP Notice:  Undefined index: delete in /var/www/vhosts/rock-o-data.de/httpdocs/khyberspace/greenbook_admin/hersteller.php on line 242, referer: http://www.rock-o-data.de/khyberspace/greenbook_admin/hersteller.php?section=2&first=0&edit=yes&entry=3
[Fri Sep 19 21:35:57 2014] [warn] [client 92.204.124.82] mod_fcgid: stderr: PHP Notice:  Undefined index: edit in /var/www/vhosts/rock-o-data.de/httpdocs/khyberspace/greenbook_admin/hersteller.php on line 251, referer: http://www.rock-o-data.de/khyberspace/greenbook_admin/hersteller.php?section=2&first=0&edit=yes&entry=3

Und wenn ich jetzt in der ersten Datenzeile ("Yamaha") auf "Bearbeiten klicke...

...kommt ein "403 Forbidden"! Was soll denn das jetzt schon wieder? Scheiße!

Ich hatte zwischenzeitlich nach deiner Empfehlung die Schreibrechte von error_log auf 644 zu ändern versucht, das war mir aber nicht erlaubt... könnte es damit etwas zu tun haben? Wie kann ich meine Datei wieder zugänglich machen?

Was ist das alles so elend kompliziert!!! Und meine Nerven sind so schwach, dass ich täglich vielleicht eine halbe Stunde an dem Ding arbeiten kann, bevor ich schon wieder fix und fertig bin... traurig, traurig!

Die Anderen (http://www.lemlem.de) fahren mit dem Fahrrad nach Afghanistan - und ich schaffe es nicht einmal, so ein popeliges Datenbanksystemchen zum Laufen zu bekommen!

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

echo "<p>Query = ".$query."</p>";  

$result = mysql_query($query);
dberror();
echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";
$db = mysql_close();
dberror();

>   
> dberror() ist definiert wie folgt:  
>   
> ~~~php

  function dberror()  

>   {  
>     if (mysql_errno())  
>     {  
>       switch(mysql_errno())  
>       {  
> 	case 1062:  
> 	  die ("Ein Eintrag mit diesen Daten existiert bereits! Bitte korrigieren Sie Ihre Eingabe!<br>");  
> 	break;  
> 	default:  
> 	  die (mysql_errno().": ".mysql_error()."<br>");  
>       }  
>     }  
>   }  
> 

Review:

> 	$db = mysql_close();  

Du schließt also die Verbindung bevor Du

> 	dberror();  

aufrufst und darin dann mysql_errno() und mysql_error(). Was soll das bringen? In der Dokumentation steht zu den Parametern:

Zitat:

Verbindungs-Kennung:

Die MySQL-Verbindung. Wird die Verbindungskennung nicht angegeben, wird die letzte durch mysql_connect() geöffnete Verbindung angenommen. Falls keine solche Verbindung gefunden wird, wird versucht, eine Verbindung aufzubauen, wie es beim Aufruf von mysql_connect() ohne Angabe von Argumenten der Fall wäre. Falls zufällig keine Verbindung gefunden oder aufgebaut werden kann, wird eine Warnung der Stufe E_WARNING erzeugt.

Wenn die Verbindung gelöst wird, dann ist auch die letzte Fehlernummer und ~Meldung im Orkus.

Korrektur:

$result = mysql_query($query) or dberror( mysql_errno(), mysql_error(), $query );  

wäre besser, denn dann kannst Du in Deiner Funktion alles auswerten.

function dberror($mysqlErrNo, $mysqlError, $query)  
  {  
    if ($mysqlErrNo)  
    {  
      switch($mysqlErrNo)  
      {  
        case 1062:  
          die ("Ein Eintrag mit diesen Daten existiert bereits! Bitte korrigieren Sie Ihre Eingabe!<br>");  
        break;  
        default:  
          die ($mysqlErrNo.": ".$mysqlError."<br>Query war: <pre>".$query."<pre>");  
      }  
    }  
  }

Besser wäre statt des 'die ($mysqlErrNo.": ".$mysqlError."<br><pre>".$query."<pre>");' einen Fehler zu triggern.

trigger_error('Von Dir gebauter Text', E_USER_ERROR);  

... wäre Dein Freund. Kombiniere das mit mit meiner use-strict-Lösung.

Jörg Reinholz

[M.]

Mahlzeit,

Kombiniere das mit mit meiner use-strict-Lösung.

Ich hab das mal überflogen. Sehe ich das richtig, dass dein Script den Fehler im Browser ausgibt und auf Wunsch bei einem Notice mit einem Fatal abbricht?

Ich nutze aktuell eigene Error-Handler im System in Verbindung mit xDebug auf dem Testserver, bin aber immer an neuen Methoden der Fehlerbehandlung interessiert.

[Jörg Reinholz]

Ich hab das mal überflogen. Sehe ich das richtig, dass dein Script den Fehler im Browser ausgibt und auf Wunsch bei einem Notice mit einem Fatal abbricht?

Ja. Das ist (grob) der Sinn von 'use strict'. Hintergrund ist, dass, wenn Notizen oder Warnungen geworfen werden, PHP weiter macht - aber die Ergebnisse nicht den erwarteten entsprechen. Das kann bei echten Webanwendungen (man denke an einen Shop) ziemlich üble Folgen haben. Zumindest auf Entwicklersystemen würde ich das so verwenden, für Produktivsysteme kann man das Skript ja auf Wunsch so umschreiben, dass der Fehler und die Umstände ($_POST, GET, SESSION, COOKIE...) an einen Admin gemailt werden, während dem Benutzer einfach nur ein "Ups! Ein Fehler! Der Admin ist informiert." gezeigt wird.

Jörg Reinholz

[Yadgar]

Hi(gh)!

Im Moment kann ich gar nicht mehr auf die Seite zugreifen - beim Versuch, mich in meinen "Administrator-Bereich" (http://www.rock-o-data.de/khyberspace/greenbook-d.php) einzuloggen, bekomme ich immer ein "403 Forbidden" - mit dem Hinweis "Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

Gestern hatte ich versucht, das error_log-File mit einer leeren Datei zu überschreiben - dabei nicht bedacht, dass nur der Webadministrator von bergisch-afghanistan.de (und das bin NICHT ich!) dort Schreibrechte hat! gFTP hat zwar ein "Access denied" (oder so ähnlich) angezeigt, trotzdem könnten meine Administrator-Seiten seither das error_log-File nicht mehr nutzen, was wohl zu dieser Fehlermeldung führt.

Was anderes: habe ich mich mit meinem Versuch, das error_log-File zu überschreiben, womöglich strafbar gemacht?

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Was anderes: habe ich mich mit meinem Versuch, das error_log-File zu überschreiben, womöglich strafbar gemacht?

MMn nein. Du solltest aber natürlich vermeiden, beim Shared-Hosting auf andere Verzeichnisse als dein eigenes zuzugreifen. Das könnte dem Hoster sauer aufstossen.

Hast du keinen lokalen Testserver? So wie du das beschreibst, arbeitest du komplett auf einem gemieteten Webspace und das ist zum Entwickeln denkbar ungeeignet.

[Yadgar]

Hi(gh)!

Hast du keinen lokalen Testserver? So wie du das beschreibst, arbeitest du komplett auf einem gemieteten Webspace und das ist zum Entwickeln denkbar ungeeignet.

Das wäre allerdings eine gute Idee, einen lokalen Testserver zu haben - auch, um MySQL zu üben!

Ich schaffe es bis jetzt nicht, LAMPP auf meiner Linux-Maschine vernünftig zum Laufen zu bringen! Wenn ich in /opt/lampp als Superuser eingebe:

/start lampp

bekomme ich als Meldungen:

Starting XAMPP for Linux 1.8.3-5...
XAMPP: Starting Apache...fail.
XAMPP:  Another web server is already running.
XAMPP: Starting MySQL...ok.
XAMPP: Starting ProFTPD...ok.

Was für ein "anderer Webserver"? Wie kann ich herausfinden, welcher - und wie kann ich diesen dann dauerhaft deaktivieren, so dass er auch standardmäßig beim Booten nicht mehr gestartet wird?

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Ich schaffe es bis jetzt nicht, LAMPP auf meiner Linux-Maschine vernünftig zum Laufen zu bringen! Wenn ich in /opt/lampp als Superuser eingebe:

Wieso machst du auch sowas? Richte Apache, PHP und Mysql aus den Paketquellen ein, die laufen idR ohne grosse Konfiguration.

[Yadgar]

Hi(gh)!

Wieso machst du auch sowas? Richte Apache, PHP und Mysql aus den Paketquellen ein, die laufen idR ohne grosse Konfiguration.

Es gibt keine Paketquellen namens php und mysql! apt-get install php bzw. apt-get install mysql funktioniert nicht!

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

Es gibt keine Paketquellen namens php und mysql! apt-get install php bzw. apt-get install mysql funktioniert nicht!

Debian, Ubuntu, Mint?

Dann installiere

sudo apt-get install php5 php5-cli libapache2-mod-php5 php5-mysql mysql-client mysql-server synaptic

Letzteres taucht dann im Menü auf und hilft Dir bei Bedarf den Rest zu installieren.

Da wären z.B. php5-sqlite php5-imagick php5-curl php5-json

Jörg Reinholz

[Yadgar]

Hi(gh)!

Debian, Ubuntu, Mint?

Debian! Und zwar stable (wheezy) 7.x

sudo apt-get install php5 php5-cli libapache2-mod-php5 php5-mysql mysql-client mysql-server synaptic

Habe ich gemacht, aber es gab Fehler:

Creating config file /etc/php5/apache2/php.ini with new version
[....] Restarting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
 failed!
invoke-rc.d: initscript apache2, action "restart" failed.

und

dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
 mysql-server hängt ab von mysql-server-5.5; aber:
  Paket mysql-server-5.5 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert

sowie

Fehler traten auf beim Bearbeiten von:
 mysql-server-5.5
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

folglich beim Eingeben von "mysql":

root@debian:/etc/apt# mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Letzteres taucht dann im Menü auf und hilft Dir bei Bedarf den Rest zu installieren.

Wie man sieht, erstmal nicht...

Bis bald im Khyberspace!

Yadgar

Now playing: Ballad Of Big (Genesis)

[Jörg Reinholz]

(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
failed!

Das ist "einfach". Da hängt schon ein Server am Port 80 und das kann immer nur einer. Es ist also (wenn nicht jemand einen anderen Dienst verbogen hat) bereits ein Webserver installiert. Hast Du die verungückte XAMPP-Installation entfernt?

was sagt denn

~> wget -d --delete-after http://localhost/

?

dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
mysql-server hängt ab von mysql-server-5.5; aber:
  Paket mysql-server-5.5 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert

Da muss es auch eine Fehlermeldung gegeben haben. Hast Du vorher die verungückte XAMPP-Installation entfernt? Vermutlich ist das Ergebnis von

~> grep mysql /var/log/dpgk*

aussagekräftig. Hilfreich ist DANN womöglich:

~> sudo dpkg-reconfigure mysql-server-5.5
und danach:
~> sudo dpkg-reconfigure mysql-server

synaptic:

Ich wüsste nicht, wieso es nicht installiert sein sollte. Es besteht keine Abhängigkeit.

Versuche es zu starten (entweder mit ~> sudo synaptic, ~> gksudo synaptic, ~> gksu synaptic). Wenn es nicht gefunden wird, dann

~> sudo apt-get install synaptic

Jörg Reinholz

[Yadgar]

Hi(gh)!

Das ist "einfach". Da hängt schon ein Server am Port 80 und das kann immer nur einer. Es ist also (wenn nicht jemand einen anderen Dienst verbogen hat) bereits ein Webserver installiert. Hast Du die verungückte XAMPP-Installation entfernt?

Kriege ich nicht hin - bekomme bei apt-get purge xampp bzw. apt-get purge lampp immer nur "Paket kann nicht gefunden werden"!

was sagt denn

~> wget -d --delete-after http://localhost/

Verbindungsaufbau zu localhost (localhost)|127.0.0.1|:80... verbunden.
Created socket 3.
Releasing 0x0000000000d32350 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: localhost
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, warte auf Antwort...
---response begin---
HTTP/1.1 200 OK
Date: Sun, 21 Sep 2014 13:44:37 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Sat, 30 Aug 2014 14:46:03 GMT
ETag: "7021e1-b1-501d9d43000c0"
Accept-Ranges: bytes
Content-Length: 177
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

---response end---
200 OK
Registered socket 3 for persistent reuse.
Länge: 177 [text/html]
In »»index.html«« speichern.

100%[=========================================================================================================================================>] 177         --.-K/s   in 0s

2014-09-21 15:44:37 (13,5 MB/s) - »»index.html«« gespeichert [177/177]

Removing file due to --delete-after in main():
Entferne »index.html«.

Und jetzt?

Da muss es auch eine Fehlermeldung gegeben haben. Hast Du vorher die verungückte XAMPP-Installation entfernt? Vermutlich ist das Ergebnis von

Ich weiß ja nicht einmal, wie (s. o.)!

~> grep mysql /var/log/dpgk*

grep: /var/log/dpgk*: Datei oder Verzeichnis nicht gefunden

Und jetzt?

~> sudo dpkg-reconfigure mysql-server-5.5

/usr/sbin/dpkg-reconfigure: mysql-server-5.5 ist kaputt oder nicht komplett installiert

und danach:
~> sudo dpkg-reconfigure mysql-server

/usr/sbin/dpkg-reconfigure: mysql-server ist kaputt oder nicht komplett installiert

Versuche es zu starten (entweder mit ~> sudo synaptic, ~> gksudo synaptic, ~> gksu synaptic).

No protocol specified
 Wenn es nicht gefunden wird, dann

~> sudo apt-get install synaptic

Gefunden wurde es ja anscheinend schon... oder doch nicht? Gesunder Menschenverstand hilft einem nicht viel, wenn man in den Innereien von Betriebssystemen herumwühlt!

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Kriege ich nicht hin - bekomme bei apt-get purge xampp bzw. apt-get purge lampp immer nur "Paket kann nicht gefunden werden"!

Hast du xampp per apt-get installiert? Wenn nicht, kannst du es damit auch nicht entfernen.
Grundsätzlich gilt, immer den Paketmanager nutzen, sonst versaust du dir auf Dauer dein System, grad mit solchen Murksereien wie Xammp unter Linux.

Und wenn es kein passendes Paket gibt, dann selber bauen. Ist nicht schwer, gibts ne Masse an Doku im Netz dazu ;)

Allerdings solltest du dir überlegen auf Mint auf Debianbasis umzusteigen.
Debian hat den "Nachteil", dass Pakete nur langsam aktualisiert werden.

Der Vorteil ist ein extrem stabiles System, der eigentliche Nachteil, wenn du aktuell sein willst, bist du ständig am Pakete bauen.

Ich mach es so: Server -> Debian/Stable, Desktop -> Mint/Debian

[Jörg Reinholz]

Server: Apache/2.2.22 (Debian)

...

Und jetzt?

Fein. Es läuft ein Apache 2.2.22 - Das war genau das, was ich wissen wollte!

~> grep mysql /var/log/dpgk*

grep: /var/log/dpgk*: Datei oder Verzeichnis nicht gefunden

Und jetzt?

-> whereis grep
(Ausgaben posten)

~> ls -l /var/log/dpgk*
(falls nichts kommt:)

~> ls -l /var/log/
(Ausgaben posten)

Ich kann mir kaum vorstellen, dass bei Bebian kein grep installiert ist. Noch weniger, dass bei Debian kein dpkg oder dessen Logfiles nicht da sein sollen.

Gefunden wurde es ja anscheinend schon... oder doch nicht? Gesunder Menschenverstand hilft einem nicht viel, wenn man in den Innereien von Betriebssystemen herumwühlt!

Doch. Aber der muss auf Kenntnissen aufbauen. Keine Angst, die kommen fast von allein. Und anders als Windows kann man es auch tun.

Jörg Reinholz

[M.]

Mahlzeit,

Ich kann mir kaum vorstellen, dass bei Bebian kein grep installiert ist. Noch weniger, dass bei Debian kein dpkg oder dessen Logfiles nicht da sein sollen.

Beides per Default da. Wenn nicht, hat jemand das System zerschossen.

[M.]

Mahlzeit,

sudo apt-get install php5 php5-cli libapache2-mod-php5 php5-mysql mysql-client mysql-server synaptic

Zwei kleine Tips. Befasse dich mit den Grundlagen deines Systems, das erspart dir Frust und viel Zeit, die du zum rumprobieren brauchst. Grad das Suchen nach Paketquellen ist essentiell, weil du nur so schnell erfährst, was es gibt.

Der zweite Tip: Nutze, anstatt apt-get lieber aptitude. Wenn noch nicht verfügbar, installieren mit

sudo apt-get aptitude

Der Vorteil, es werden alle Abhängigkeiten gespeichert, also werden bei der Entfernung per Aptitude auch nicht mehr benötigte Pakete mit entfernt.

Suchen:
sudo aptitude search STRING

Installieren
sudo aptitude install PAKET

Entfernen inkl. aller Config-Dateien:
sudo aptitude purge PAKET

Update aller Pakete:
sudo aptitude update && sudo aptitude upgrade

Damit solltest du schonmal was anfangen können.

Für die Logfiles machst du folgendes im Terminal:
tail -f /var/log/apache/error.log

Das zeigt dir das error-log des Indianders an und aktualisiert selbst.
Wenn du dir dann noch xdebug installierst wirst du merken, wie einfach die PHP-Entwicklung sein kann, wenn der Server klartext spricht ;)

[Yadgar]

Hi(gh)!

Mahlzeit,

sudo apt-get install php5 php5-cli libapache2-mod-php5 php5-mysql mysql-client mysql-server synaptic

Zwei kleine Tips. Befasse dich mit den Grundlagen deines Systems,

Das ist so entsetzlich viel, das schaffe ich doch nie!

Der zweite Tip: Nutze, anstatt apt-get lieber aptitude. Wenn noch nicht verfügbar, installieren mit

sudo apt-get aptitude

Jetzt habe ich gerade aptitude installiert - und schon beim Installieren wurde der MySQL-Server korrekt eingerichtet, ich kann jetzt problemlos mit

mysql -u root -p

und anschließener Passworteingabe MySQL starten! Verrückt!!!

Danke für den Tipp! Wenn ich jetzt noch erfahren würde, wie ich von meiner Systempartition einen im Ernstfall benutzbaren Backup erstelle, ist meine Computerwelt fast schon wieder in Ordnung...

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Wenn ich jetzt noch erfahren würde, wie ich von meiner Systempartition einen im Ernstfall benutzbaren Backup erstelle, ist meine Computerwelt fast schon wieder in Ordnung...

Wenn du eine Festplatte mit gleicher Grösse hast, einbauen und per dd ein komplettes Abbild erstellen.
Alternativ geht, auch mit dd, eine Imagedatei, die du bei Bedarf wieder zurückspielen kannst.

Auf Dateiebene kannst du rsync nutzen, das erzeugt aber keine startbare Kopie sondern nur ein inkrementelles Backup (oder ein komplettes, wenn du es willst). Genaueres in der Manpage.

[Yadgar]

Hi(gh)!

Wenn du eine Festplatte mit gleicher Grösse hast, einbauen und per dd ein komplettes Abbild erstellen.

Würde das auch mit einer externen Festplatte funktionieren?

Alternativ geht, auch mit dd, eine Imagedatei, die du bei Bedarf wieder zurückspielen kannst.

In der Manpage von dd ist aber von Imagedateien nicht die Rede... wo muss ich da nachsehen?

Kann ich im Falle eines Falles (der hoffentlich so bald nicht auftritt, es ist nämlich extrem nervend, das ganze System "from scratch" wieder aufzubauen, wenn man eben kein fertiges Partitions-Image hat!) die Systempartition aus diesem Image von jeder halbwegs aktuellen Debian-Live-DVD aus wiederherstellen?

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Würde das auch mit einer externen Festplatte funktionieren?

Mit jedem beliebigen Datenträger, nur gross genug muss er sein. Aus SD-Karte oder USB-Stick würde gehen.

In der Manpage von dd ist aber von Imagedateien nicht die Rede... wo muss ich da nachsehen?

dd if=/dev/sda of=datei.img

Würde mich wundern, wenns nicht drinsteht.

Kann ich im Falle eines Falles (der hoffentlich so bald nicht auftritt, es ist nämlich extrem nervend, das ganze System "from scratch" wieder aufzubauen, wenn man eben kein fertiges Partitions-Image hat!) die Systempartition aus diesem Image von jeder halbwegs aktuellen Debian-Live-DVD aus wiederherstellen?

Du wirst dir keine Zeit sparen. Bis du mit dd das Image wieder auf die Platte geschrieben hast, hast du auch neu installiert. Erfahrungswert.

[Yadgar]

Hi(gh)!

Du wirst dir keine Zeit sparen. Bis du mit dd das Image wieder auf die Platte geschrieben hast, hast du auch neu installiert. Erfahrungswert.

Zeit vielleicht nicht... aber Nerven, da sämtliche "Nachinstallationen" (wie eben dieser nervende Apache-Server) schon mit enthalten sind!

Bis bald im Khyberspace!

Yadgar

[Yadgar]

Hi(gh)!

dd if=/dev/sda of=datei.img

Du wirst dir keine Zeit sparen. Bis du mit dd das Image wieder auf die Platte geschrieben hast, hast du auch neu installiert. Erfahrungswert.

Und zum Wiederherstellen würde man einfach

dd if=/media/[UUID]/datei.img of=/dev/sda eingeben?

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

dd if=/media/[UUID]/datei.img of=/dev/sda eingeben?

Jein ;)
Da du ja von einem anderen Medium booten musst, kann es sein, dass sich die Device-namen verschieben. Das musst du natürlich vorher prüfen.

Aber grundsätzlich ist der Befehl richtig.

Du musst dabei aber gut aufpassen, da du die Festplatte ohne Rückfrage überschreibst, und wenn noch Daten drauf waren, die du noch brauchst, hast du ein Problem.
Immer 3mal prüfen ob alles passt, bevor du sowas radikales machst.

[Jörg Reinholz]

Danke für den Tipp! Wenn ich jetzt noch erfahren würde, wie ich von meiner Systempartition einen im Ernstfall benutzbaren Backup erstelle, ist meine Computerwelt fast schon wieder in Ordnung...

dd ist schon mal eine der vielen guten Ideen.

Zuerst müssen wir wissen, was Deine Systempartition ist. Das steht  in /etc/fstab oder besser noch in /etc/mtab - dort in der ersten Zeile:

Bei mir:
~> less /etc/mtab

/dev/sda2 / ext4 rw,noatime,errors=remount-ro 0 0

1. Spalte: /dev/sda2 ist die der Name der Partition
2. Spalte: diese ist nach / gemountet (als die "Systempartition")
3. Spalte: verwendetes Dateisystem
...

~> df -h /dev/sda2 gibt bei mir dann aus:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2       103G     11G   87G   11% /

Hinweis 1:
Das ist bei mir so wenig, weil alle DATEN bei mir auf einer anderen Platte liegen. Es wird also wahrscheinlich bei Dir womöglich deutlich mehr sein.

Hinweis 2:
Das es BEI MIR /dev/sda2 ist kann ich mir auch mit

-> head -n1 /etc/mtab | cut -d " " -f1

anzeigen lassen. (Du auch!)

Ok. Jetzt will ich 103 Gigabyte als gepacktes(!) Image sichern. Problem ist, dass auf der Platte gelöschte Daten nur als gelöscht markiert sind. Packe ich das Image einfach ein, dann packe ich die gelöschten Daten mit ein. Keine gute Idee, denn  frisst Zeit und Platz. Ich überschreibe also den im Dateisystem als frei markierten Plattenspeicher in dem ich eine Datei anlege und mit logischen Nullen fülle:

-> sudo dd if=/dev/zero of=/tmp/nullen bs=8192
(Dabei sollten, ich fülle ja die Platte bis zum Rand, keine Programme laufen)
 warten bis das abbricht, das kann dauern)

und dann sofort wieder lösche:

-> sudo rm /dev/nullen

Jetzt eine USB-Platte anschließen und mounten (z.B. durch öffnen im Dateimanager). Das ist dann (im Dateimanager erkennbar) BEI MIR mir das Verzeichnis /local_mounts/backup_extern_001/ (Hab ich so eingerichtet, heißt bei Dir anders.)

Ich erinnere daran, dass /dev/sda2 BEI MIR die "Systempartition" ist.

Danach:

~> sudo dd if=/dev/sda2  | gzip -c > /local_mounts/backup_extern_001/linux_sysdisk_sda2.gz

Das rödelt bei mir rund 40 Minuten. Die Dauer ist von der Geschwindigkeit der Platten, der Art deren Anbindung (USB2/USB3) und der Prozessorleistung abhängig. Das Zippen spart dennoch meist Zeit.

Ergebnis ist bei mir eine gepackte Datei /local_mounts/backup_extern_001/linux_sysdisk_sda2.gz in der Größe von rund 6 Gigabyte (sonst werden die vollen 103 Gigabyte gebraucht).

Zum Wiederherstellen vom USB-Stick booten. Mit gparted (oder ähnlichem) herausfinden als was die "Systempartition" jetzt erkannt wird (Nehmen wir jetzt mal /dev/sdb2 an) und dann muss man noch die USB-Platte mit dem gepackten Image mounten. (das sei jetzt mal der Ordner /mnt). Nach:

~> gzip -d -c < /mnt/linux_sysdisk_sda2.gz | dd of=/dev/sdb2

lange genug warten und wenn es klappt ist man fertig.

*** Wichtig ***
Wenn nicht, dann hat man beim Ermitteln der Partition was falsch gemacht und womöglich Daten Überschrieben
***************

Hinweis: hat man die Möglichkeit und den Platz, um die Datei linux_sysdisk_sda2.gz zu entpacken (gzip -d linux_sysdisk_sda2.gz) dann kann man die resultierende Datei linux_sysdisk_sda2sogar wie eine Platte mounten und (aus mnt) einzelne Dateien herunterkopieren:

sudo mount -o loop,ro  linux_sysdisk_sda2.gz /mnt

Dir ist das zu kompliziert?

Informiere Dich über tar! Du kannst mit:

sudo tar --exclude /mounts/* -c -z -f /mounts//backup_extern_001/backup.tar.gz /

ein komplettes, gepacktes Archiv erstellen und mit

tar -x -z -f  /mounts/backup_extern_001/backup.tar.gz /mnt

wieder herstellen, wenn die Systempartition nach /mnt gemountet und geleert wurde. Man kann daraus auch einzelne Dateien wieder herstellen.

Informiere Dich auch über rsync! Damit kannst Du eine 1:1 Kopie der Dateien und Verzeichnisse herstellen und sogar über das Netzwerk (via laufendem ssh-Dämon) speichern.

Jörg Reinholz

[Jörg Reinholz]

Ich schaffe es bis jetzt nicht, LAMPP auf meiner Linux-Maschine vernünftig zum Laufen zu bringen! Wenn ich in /opt/lampp als Superuser eingebe:

Hä?

/start lampp

Hä?

bekomme ich als Meldungen:

Starting XAMPP for Linux 1.8.3-5...

Ich habe mich erst mal davon überzeugen müssen, dass es  XAMPP for Linux tatsächlich gibt. Das zu installieren ist auch keine gute Idee. Selbst unter Windows verursacht das aus meiner Sicht nur Ärger und wegen der Ordner auch irre viel Tipparbeit. Will man man mal mehr, dann muss erst mal schauen, was die Jungs alles in den Konfigurationsdateien "verbogen" haben.

Was für ein "anderer Webserver"?

Tja. LAMPP bedeutet:

A - Apache
M - MySQL
P - Perl
P - PHP

All das kannst Du am besten einfachsten und praktischsten mit dem Paketmanager Deiner Distribution installieren. Niemand braucht XAMPP for Linux ... schmeiß das wieder runter.

Der "andere Webserver" wurde auch so installiert. Welcher das ist, kannst Du mittels eines Studiums der Ausgaben des Kommandos

~> wget -d --delete-after http://localhost

oder aber mit Deinem Paketmanager oder mit einem Blick ins Dateisystem, z.B. nach /etc/init.d herausfinden.

Perl dürfte auch installiert sein, das gehört zur Grundausstattung. PHP und MySQL nicht. Kann aber sein, dass auch diese bereits installiert sind. Ich weiß ja nicht warum der Webserver installiert wurde. Stichwort: Paketabhängigkeiten.

Jörg Reinholz

[M.]

Mahlzeit,

Ich habe mich erst mal davon überzeugen müssen, dass es  XAMPP for Linux tatsächlich gibt.

Die Existenz hab ich nie verstanden. Das ist definitiv eines der Dinge, die die Welt nie braucht.

[Jörg Reinholz]

Hi(gh)!

Im Moment kann ich gar nicht mehr auf die Seite zugreifen - beim Versuch, mich in meinen "Administrator-Bereich" (http://www.rock-o-data.de/khyberspace/greenbook-d.php) einzuloggen, bekomme ich immer ein "403 Forbidden" - mit dem Hinweis "Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

http://www.rock-o-data.de/khyberspace/greenbook-d.php geht doch?

Nur wenn man sich vertippt, dann kommt:

The requested URL /khyberspace/gibts_es_nicht was not found on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Für den fall des Fehlers 404 ist eine Fehlerseite konfiguriert. Diese darf aber nicht angezeigt werden. Vermutlich liegt das an den Dateisystemrechten. Etwas wie

~> chmod 644 error_403.html

kann das beheben.

[Yadgar]

Hi(gh)!

http://www.rock-o-data.de/khyberspace/greenbook-d.php geht doch?

Nein, diese Seite meinte ich nicht... ich meinte die Administrator-Seiten, die eigentlich von dort nach Passworteingabe zugänglich sein sollten - wenn ich mich da einlogge, bekomme ich den 403er mit erwähntem Zusatzhinweis!

Bis bald im Khyberspace!

Yadgar

[Yadgar]

Hi(gh)!

Lege ein im Serverroot ein Verzeichnis "logs" an. Setze dessen Eigenschaften so, dass JEDER es betreten kann.

Geht nicht, da schon vorhanden... also habe ich ein Verzeichnis "newlogs" erzeugt.

Lege darin eine Datei "logfile" an. Setze deren Eigenschaften so, dass JEDER (insbesondere der WEBSERVER!) diese lesen und schreiben kann. (Nicht: ausführen!)

Habe ich gemacht, dann chmod 666... und was passiert: ich kann mein eigenes Verzeichnis nicht mehr lesen, weder mit FTP noch mit dem Browser - ich bekomme nur noch 403er! Klasse!

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Habe ich gemacht, dann chmod 666... und was passiert: ich kann mein eigenes Verzeichnis nicht mehr lesen, weder mit FTP noch mit dem Browser - ich bekomme nur noch 403er! Klasse!

Du solltest nicht einfach nur irgendwas machen sondern dich vorher informieren _was_ du da machst.
Oder schneidest du dich erstmal in den Finger, um zu lernen, dass ein Messer scharf ist?

[Yadgar]

Mahlzeit,

Habe ich gemacht, dann chmod 666... und was passiert: ich kann mein eigenes Verzeichnis nicht mehr lesen, weder mit FTP noch mit dem Browser - ich bekomme nur noch 403er! Klasse!

Du solltest nicht einfach nur irgendwas machen sondern dich vorher informieren _was_ du da machst.
Oder schneidest du dich erstmal in den Finger, um zu lernen, dass ein Messer scharf ist?

Zwischenzeitlich hat der Admin meines Providers den Webspace gelöscht, die Domain neu eingerichtet, so dass ich meine Daten wieder neu rüberkopieren konnte... Tests mache ich allerdings von nun an wirklich auf meinem Testserver, der jetzt auch einwandfrei läuft!

Bis bald im Khyberspace!

Yadgar

[Yadgar]

Hi(gh)!

Also noch mal neu, diesmal auf dem lokalen Testserver:

Lege ein im Serverroot ein Verzeichnis "logs" an. Setze dessen Eigenschaften so, dass JEDER es betreten kann.

Habe ich gemacht...

Lege darin eine Datei "logfile" an. Setze deren Eigenschaften so, dass JEDER (insbesondere der WEBSERVER!) diese lesen und schreiben kann. (Nicht: ausführen!)

Habe ich gemacht...

Hole:
http://www.fastix.org/r/use_strict.txt und speichere diese als

use_strict.php

im Serverroot.

Habe ich gemacht...

Stelle in die erste Zeile Deines Skriptes

<?php

define('DEBUG', 2); require_once( $_SERVER['DOCUMENT_ROOT'] . '/use_strict.php' );

>   
> 4.)  
> nimm  
> entweder 4a)  
> ~~~php
  

> error_log($query, 3, $_SERVER['DOCUMENT_ROOT'] . '/logs/logfile]' );  
> 

Habe ich gemacht... jetzt die Probe aufs Exempel:

hersteller.php aufrufen...
Untermenüpunkt "Vorhandene Datensätze editieren" aufrufen...

Aha! Fehler in Zeile 100:

$_GET['section'] ist beim Erstaufruf der Seite natürlich noch nicht gesetzt! Also ändere ich den Link in der Navigationsleiste auf "hersteller.php?section=0"... dann wird keine Fehlermeldung mehr angezeigt und ich sehe die beiden Links auf die Hauptfunktionen der Seite: "Datensätze hinzufügen" und "Vorhandene Datensätze bearbeiten".

Ich klicke auf "Vorhandene Datensätze bearbeiten":

Boinks! Nächster Fehler in Zeile 188:

$_GET['sort'] ist noch nicht gesetzt. Auch klar, denn es wird erst beim ersten Aufruf eines der Links auf den Kopfzeilen der Datensatzliste gesetzt... also füge ich dem Link auf "Vorhandene Datensätze bearbeiten" ein "&sort=0" hinzu.

Nächster Fehler: Zeile 230:

$_GET['delete'] ist noch nicht gesetzt. Also noch ein "&delete=no" in den Link auf "Vorhandene Datensätze bearbeiten"!

Nächster Fehler: Zeile 251:

$_GET['edit'] ist nicht gesetzt. Also noch ein "&edit=no" in den Link auf "Vorhandene Datensätze bearbeiten"!

Keine weiteren Fehlermeldungen, die ersten 20 Datensätze werden kommentarlos angezeigt!

Ich klicke jetzt auf "Bearbeiten" neben dem ersten Datensatz (Index-Nummer 3!)...

Wieder Fehler in Zeile 188:

$_GET['sort'] ist nicht gesetzt, weil es in den Links auf "Bearbeiten" fehlt... es empfiehlt sich hier, den jeweils bisherigen Wert zu übernehmen, also:

  
echo '<td class="headrow"><span class="b"><a href="hersteller.php?section=2&first='.floor($j/20).'&delete=pre&entry='.$row[0].'">Löschen</a></span></td><td class="headrow"><span class="b"><a href="hersteller.php?section=2&first='.floor($j/20).'&edit=yes&entry='.$row[0].'&sort='.$sort.'">Bearbeiten</a></span></td><td align="right">'.$row[0]."</td><td>".$row[1]."</td><td>".$row[2]."</td><td>".$row[3]."</td><td>".$row[4]."</td></tr>";  

Noch ein Fehler in Zeile 230 - das gleiche Spiel mit $_GET['delete']... also füge ich in Zeile 213 ein:

  
$delete = $_GET['delete'];  

um nicht mit der umständlicheren Array-Schreibweise hantieren zu müssen und füge in die Links (sie werden in einer while-Schleife erzeugt, jeweils für 20 Datensätze) auf "Bearbeiten" noch &delete='.$delete. ein.

Jetzt wird beim Klicken auf "Bearbeiten" immerhin schon nach "Hallo!" die Testausgabe mit der ausgewählten Index-Nummer (in diesem Fall die 3):

  
echo "<p>entry = ".$entry."</p>";  

angezeigt, das funktionierte vorher nicht... allerdings bekomme ich jetzt noch eine Fehlermeldung, und zwar in Zeile 36:

Die Variable $s ist nicht definiert - es handelt sich dabei um einen Coderest, der eigentlich schon auskommentiert sein sollte, in besagter Zeile sollte $s (enthält den aktuellen Wert von $_GET['section']) ausgegeben werden. Ich entferne die Zeile, ebenso wie die bereits auskommentierte Deklaration von $s.

Jetzt wird es allerdings haarig: die nächste Fehlermeldung verweist auf Zeile 66:

$_POST['Firmenname'] (und analog die anderen normalerweise mit dem ausgefüllten Eingabeformular übermittelten Feldwerte) ist nicht gesetzt - kann ja auch nicht, da ja im Falle von edit=yes erst einmal nur das Eingabeformular (mit den Feldwerten aus dem Datensatz entsprechend des Wertes von $entry) angezeigt wird, aber noch keine Daten abgeschickt wurden. $Firmenname (und entsprechend die anderen Datenfeldvariablen) muss also im Fall von edit=yes seinen Wert aus dem eingelesenen Datensatz erhalten:

if ($_GET['edit']=="yes")  
{  
  $Firmenname = $row[1];  
  $Land = $row[2];  
  $Status = $row[3];  
  $Link = $row[4];  
}  
else  
{  
  $Firmenname = $_POST['Firmenname'];  
  $Land = $_POST['Land'];  
  $Status = $_POST['Status'];  
  $Link = $_POST['Link'];  
}  

Damit komme ich auch der Lösung meines eigentlichen Problems näher: denn wenn $Firmenname nicht bekannt war, konnte natürlich auch die switch-Verzweigung entsprechend dem Wert von $_GET['section'] nicht durchlaufen werden, ich bekam stattdessen immer die Meldung "Es wurden keine Datensätze eingegeben". Siehe hier:

if (!$Firmenname)  
{  
  echo "Sie haben keine Daten eingegeben!<br>";  
}  
else  
{  
  dbcall();  
  switch ($_GET['section'])  
  {  
    case 1:  
      $query = "INSERT INTO hersteller (Firmenname, Land, Status, Link) VALUES ('".mysql_real_escape_string($Firmenname)."','".mysql_real_escape_string($Land)."','".mysql_real_escape_string($Status)."','".mysql_real_escape_string($Link)."')";  
    break;  
    case 2:  
      $query = "UPDATE hersteller SET Firmenname='".mysql_real_escape_string($Firmenname)."', Land='".mysql_real_escape_string($Land)."', Status='".mysql_real_escape_string($Status)."', Link='".mysql_real_escape_string($Link)."' WHERE ID=".$entry;  
	    error_log($query, 3, $_SERVER['DOCUMENT_ROOT'] . '/logs/logfile]' );  
    break;  
    default:  
      echo "<p>section = ".$_GET['section']."</p>";  
  }  
  echo "<p>Query = ".$query."</p>";  
  $result = mysql_query($query);  
  dberror();  
  echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";  
  $db = mysql_close();  
  dberror();  
}  

Jetzt sollte nicht nur der UPDATE-Query korrekt ausgeführt werden, sondern auch angezeigt werden - womit das Abfangen im Errorlog (erst einmal) nicht notwendig gewesen wäre.

Der Test:

Jetzt passiert etwas, was ich so nicht beabsichtigt hatte: der UPDATE-Query wird ausgeführt und angezeigt, allerdings noch mit den alten Datenfeldwerten, d. h. der Datensatz wird bereits "geändert" (faktisch schon, da ja der Inhalt des Feldes "Firmenname" nur bis zum ersten Whitespace übernommen wurde), bevor ich überhaupt den/die neuen Wert/e eintragen und auf "Daten absenden" klicken konnte. Vor allem aber erscheint wieder eine Fehlermeldung, diesmal in Zeile 196 (die ehemalige 188, durch meine Code-Einfügungen haben sich natürlich die Zeilennummern geändert): $_GET['sort'] ist aktuell nicht definiert.

Dabei müsste es doch bekannt sein, denn im Link zu "Bearbeiten" wird auch sort (entsprechend der jeweiligen Datensatzzeile) übertragen! Ich verstehe das nicht...

...und jetzt bin ich auch schon wieder zu müde, um weiter zu arbeiten! Wie machen das eigentlich die Profis, die doch angeblich regelmäßig drei Tage und Nächte am Stück durchprogrammieren?

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

$_GET['section'] ist beim Erstaufruf der Seite natürlich noch nicht gesetzt!

Entweder prüfst du auf vorhandensein mit isset() oder initialisierst deine Variablen. Gut, letzteres ist mit $_GET eher weniger sinnvoll, aber grundsätzlich macht es mehr sinn, die Existenz zu prüfen als per URL einen Defaultwert zuzweisen. Das erleichtert die Arbeit, wenn du an anderer Stele drauf zugreifst oder irgendwas am HTML änderst.

[Yadgar]

Hi(gh)!

Entweder prüfst du auf vorhandensein mit isset() oder initialisierst deine Variablen. Gut, letzteres ist mit $_GET eher weniger sinnvoll, aber grundsätzlich macht es mehr sinn, die Existenz zu prüfen als per URL einen Defaultwert zuzweisen. Das erleichtert die Arbeit, wenn du an anderer Stele drauf zugreifst oder irgendwas am HTML änderst.

Ich habe es zuerst auch mit mit isset() versucht, das führte aber nur dazu, dass das Fenster komplett weiß blieb... I bin hoit bled!

Bis bald im Khyberspace!

Yadgar

[M.]

Mahlzeit,

Ich habe es zuerst auch mit mit isset() versucht, das führte aber nur dazu, dass das Fenster komplett weiß blieb... I bin hoit bled!

Das ist aber idR ein Zeichen für einen fatalen Fehler. Das heisst, es könnte eine Klammer, ein ; o.ä. fehlen. Das sagst dir aber dein error.log, das du jetzt auf dem Testserver zur Verfügung hast ;)

[Jörg Reinholz]

Wie machen das eigentlich die Profis, die doch angeblich regelmäßig drei Tage und Nächte am Stück durchprogrammieren?

Richtige Profis machen genau das nicht. Jedenfalls nicht freiwillig.

Jörg Reinholz

[Yadgar]

Also sagen wir ihm doch besser, dass wir vermuten, dass

WHERE ID=".$entry;

Vielleicht

WHERE ID=".$Entry

heißen soll (die anderen Variablen beginnen auch groß und genau das könnte zum bestens mysql-syntax-error passen).

Nein, $entry ist tatsächlich als $entry gemeint, ich habe mir den Code nochmal angesehen!

[Jörg Reinholz]

Wie wäre es denn damit die $query _vorher_ zu loggen?
Vorher? Bevor der String überhaupt zugewiesen wurde? Was soll denn das?

Nein! Bevor der String an die Datenbank geschickt wird.
Ich habe das mal für Dich gemacht:

<?php $Firmenname="foo' GmbH";
$Land="DE";
$Status=1;
$Link="viel text";
$entry=100;
$_GET['section']=2;
$DB=mysql_connect('####', '###', '###'); # Deine Werte...

if (!$Firmenname)
      {
        echo "Sie haben keine Daten eingegeben!<br>";
      }
      else
      {
        dbcall();
        switch ($_GET['section'])
        {
          case 1:
            $query = "INSERT INTO hersteller (Firmenname, Land, Status, Link) VALUES ('".mysql_real_escape_string($Firmenname)."','".mysql_real_escape_string($Land)."','".mysql_real_escape_string($Status)."','".mysql_real_escape_string($Link)."')";
          break;
          case 2:
            $query = "UPDATE hersteller SET Firmenname='".mysql_real_escape_string($Firmenname)."', Land='".mysql_real_escape_string($Land)."', Status='".mysql_real_escape_string($Status)."', Link='".mysql_real_escape_string($Link)."' WHERE ID=".$entry;
          break;
        }

Meine Zeile

error_log("\n".$query, 3, "/tmp/query.log");
##############################
        #$result = mysql_query($query);
        dberror();
        echo "Ihre Eingabe war korrekt und wurde in die Datenbank eingetragen!";
        $db = mysql_close();
        dberror();
      }

function dbcall() {
  return true;
}

function dberror() {
  return true;
}
?>

Resultat in /tmp/query.log:

UPDATE hersteller SET Firmenname='foo' GmbH', Land='DE', Status='1', Link='viel text' WHERE ID=100

(wird jeweils angehängt)

Jörg Reinholz

[Yadgar]

Nein! Bevor der String an die Datenbank geschickt wird.
Ich habe das mal für Dich gemacht:

}

Meine Zeile

error_log("\n".$query, 3, "/tmp/query.log");
##############################
        #$result = mysql_query($query);

Funktioniert auch nicht... ich habe zwischenzeitlich mit phpinfo() festgestellt, dass die Systemvariable error_log keinen Wert hat! Könnte es damit was zu tun haben?

Bis bald im Khyberspace!

Yadgar

[Jörg Reinholz]

error_log("\n".$query, 3, "/tmp/query.log");

Funktioniert auch nicht... ich habe zwischenzeitlich mit phpinfo() festgestellt, dass die Systemvariable error_log keinen Wert hat! Könnte es damit was zu tun haben?

In dem Fall eher nicht. Die logdatei wird habe ich absichtlich explizit angegeben, weil error_log() ohne Angabe der Datei nicht funktionieren kann, wenn PHP nicht als Modul sondern als CLI läuft. (Ich hatte es auch in einem Terminal ausgeführt.)

Das dürfte auch der häufigste Fall auf älteren Installationen sein, die bei manchen Hostern halt noch laufen, damit ältere Skripte der Kunden nicht den Bach runter gehen.

Jörg Reinholz

[ChrisB]

Hi,

Durch sukzessives Auskommentieren habe ich herausgefunden, dass der Fehler im case 2-Block liegt (der Querystring in case 1 wird korrekt verarbeitet)... und error_log($query) wird erst gar nicht ausgeführt, weil das Programm schon vorher abbricht...

Bricht es wirklich ab? Dann solltest du Hinweise zum Fehler, der zum Abbruch führte, in den üblichen Quellen finden. (Korrekt konfigurierte error reportin vorausgesetzt.)

Oder wird vielleicht der Code, den du in diesem case-Block notiert hast, einfach nur nicht ausgeführt – weil die „case-Bedingung“ gar nicht erfüllt war …?
Überprüfe(!) das bitte erst mal – $_GET['section'] mit var_dump ausgeben, einen default-Zweig hinzufügen der nur einen Hinweis ausgibt *dass* der switch im default-Zweig gelandet ist; etc.

MfG ChrisB