UPDATE funzt nie

[PHP-Desaster]

Gute nacht ihr PHP-Profis!

sitze inzwischen seit einigen Stunden an eine Klasse, die Session in einer Datenbank speichert! Nur leider scheitere ich absolut an dem Fehler, warum folgendes Query keine Daten in die Datenbank einfügt:

$query = "UPDATE session SET vars='".( $mysql->real_escape_string(
  serialize( $sessionvars ) ) )."' WHERE s_id LIKE '".$sessionid."';";
$mysql->query( $query );
if( !$mysql->affected_rows() ) {
   $this->_trigger_error( "Daten konnten nicht gespeichert werden!" );
} 

Lass ich mir das Query ausgeben, erhalte ich zum Beispiel folgendes für ein leeres Array:

UPDATE sessions SET vars='a:0:{}' WHERE s_id LIKE '5a8b8ef624b71495071da3c0e1ef10d2';

Nur ist die Sache, das der Datensatz in der Datenbank nicht aktualisiert wird!! Natürlich gibt es einen mit dieser sessionid!
Als Fehlermeldung bekomme ich folgendes:

Session: Daten konnten nicht gespeichert werden!
at line XXXin Datei: XXXsession.class.php 

was darauf schließt, das das Query nicht erfolgreich war! MySQL-Fehlermeldungen bekomme ich nicht, die würden aufgrund von Exceptions in der Mysql-Klasse sofort rausfliegen!
So, jetzt die Frage, wo könnte der Grund liegen?? Hab ich schwachsinn in meinem Query??

Neue Datensätze mit der Klasse anlegen und bereits vorhandene Sessions wieder aufnehmen funzt fehlerlos, nur das aktualisieren funktioniert nicht!!

[subabrain]

$query = "UPDATE session SET vars='".( $mysql->real_escape_string(
  serialize( $sessionvars ) ) )."' WHERE s_id LIKE '".$sessionid."';"; 

was is das für ein string?

also ich sehe hier 2 absolut verwirrende sachen ... evtl. kommst du ja selber drauf

falls nicht


gn8
Robert

[heiss]

erstens heisst es in diesem Fall nicht LIKE sondern =.
zweitens ist affected_rows die Anzahl der tatsächlich geänderten Zeilen, dh mit anderen Werten als vorher. Wenn die Werte nicht ändern ist es 0.

Für deine Fragestellung ist mysql_info() zuständig, Du erhältst Du zB.
UPDATE
String format: Rows matched: 65 Changed: 65 Warnings: 0

drittens gefällt mir $mysql-> nicht ganz, üblich ist mysql_ .
viertens erhältst Du nicht eine Fehlermeldung, sondern produzierst selber eine, wenn mysql_affected_rows() ==0 ist.
Ferner sollte mysql_error() verwendet werden, aber das macht deine _trigger_error vielleicht.

[edits]
ich kann mir gut vorstellen, dass bei

UPDATE sessions SET vars='a:0: { }' WHERE s_id LIKE '5a8b8ef624b71495071da3c0e1ef10d2';

nichts tatsächlich geändert wird . Dein array $sessionvars ist leer.
(NB smiley mit leerzeichen gestört).

Die Drei Zahlen im mysql_info string bekommt man mit preg_split('#D+#',...) heraus:
list(,$matched,$changed,$warnings)=preg_split('#D+#',$mysql_info()) ;
aktueller Code ungetestet, aber so ähnlich habe ich es gemacht. Ein U modifier ist anscheinend nicht nötig..


Sonst ist dein Code in Ordnung sowas ordentliches sieht man hier eher selten.

[phoboslab]

Original geschrieben von heiss
drittens gefällt mir $mysql-> nicht ganz, üblich ist mysql_ .

0_o


Übrigens sollten die Anfragen, die man mit mysql_query abschickt, ohne abschließendes Semikolon gesendet werden. Also statt:

$q = 'SELECT * FROM tabelle;'; 

einfach:

$q = 'SELECT * FROM tabelle'; 

Wobei das Semikolon afaik auch kein Grund zum scheitern des Querys ist.

[ghostgambler]

Original geschrieben von heiss
Für deine Fragestellung ist mysql_info() zuständig, Du erhältst Du zB.
UPDATE
String format: Rows matched: 65 Changed: 65 Warnings: 0

Und dann preg_match oder was? Oo,

if (mysql_error($connection) != 0) {
  echo 'fehler';
} else {
  echo 'korrekt';
} 

drittens gefällt mir $mysql-> nicht ganz, üblich ist mysql_ .

Nachdem es auch eine Methode query gibt, wird das wohl ein eigenes Objekt sein...

[heiss]

@ghostgambler

mysql_info und preg_split sind die kompaktesten, und übersichtlichsten Weisen genau das abzufragen was in der Logik von Frager ist. Sonst wird wegen einem kleinen Fehler die ganze Programmabschnittsstruktur über den Haufen geworfen. Es ist legitim zu schauen ob session-id getroffen wurde.

[heiss]

Original geschrieben von phoboslab
Wobei das Semikolon afaik auch kein Grund zum scheitern des Querys ist.

Die Query, wie beschrieben, ist nicht gescheitert. Man muss das aber so abfragen wie ich vorgeschlagen habe und nicht so, wie Frager während einigen Stunden gedacht hat.

[PHP-Desaster]

$query = "UPDATE session SET vars='".( $mysql->real_escape_string(
  serialize( $sessionvars ) ) )."' WHERE s_id LIKE '".$sessionid."';"; 

was is das für ein string?

also ich sehe hier 2 absolut verwirrende sachen ... evtl. kommst du ja selber drauf

ich kann mir beim besten willen nicht vorstellen, worauf du hinauswillst!!

das $mysql-> richtig ist, liegt einfach daran, dass das ein Objekt einer Mysqlklasse ist! macht im grunde aber kein Unterschied!

Das mit dem Semikolon am Ende hab ich so gelernt gehabt und nicht gewusst, das die bei mysql_query nicht mit angehangen werden müssen, aber da es im grunde eh egal ist,...

MySQL-Fehlermeldungen bekomme ich nicht, die würden aufgrund von Exceptions in der Mysql-Klasse sofort rausfliegen!

der aufmerksame leser sieht, dass eventuelle Fehler beim Query sofort per Exceptions rausgeflogen wären!!

Nichts desto trotz, danke ich euch für eure antworten und ich werde mir sofort mal mysql_info ansehen und ausprobieren!! Ich habe nicht gewusst, das affected_rows nichts zurückgibt, wenn das query nichts verändert hat! Und das mit dem = statt LIKE hatte ich vorher, hatte aber auch nicht geklappt!! aber ich machs jetzt anders

Besten dank leute!!!

[PHP-Desaster]

Super Leute, es funktioniert wie eine Eins!! Wie dumm es doch ist, an solch "billigen" Dingen zu scheitern... Naja, war ja schon spät

[heiss]

Original geschrieben von PHP-Desaster
[BDas mit dem Semikolon am Ende hab ich so gelernt gehabt und nicht gewusst, das die bei mysql_query nicht mit angehangen werden müssen, aber da es im grunde eh egal ist,...
[/B]

Das mit dem Semikolon wollen wir noch gerade stellen:

in phpMyAdmin kann man mehrere sql-Befehle auf einmal aufgeben, diese werden mit Semikolon getrennt.
in mysql_query geht nur ein Befehl aufs mal, der Rest wird (ignoriert|gibt Fehlermeldung). mit Semikolon hast Du den Befehl, und noch einen Leerbefehl. Die Empfehlung ist, am Schluss des sql-Befehls kein sql-Semikolon zu haben.

[PHP-Desaster]

aber wieso?? ich kann das doch einfach so abschließen und für mich terminieren, oder ist das eher unschön?? hab das ehrlich immer so gemacht bis jetzt!!

[heiss]

Original geschrieben von PHP-Desaster
aber wieso?? ich kann das doch einfach so abschließen und für mich terminieren, oder ist das eher unschön?? hab das ehrlich immer so gemacht bis jetzt!!

Original geschrieben im php-Manual
mysql_query() Parameters query A SQL query The query string should not end with a semicolon.

siehe also php-Manual

[ghostgambler]

Original geschrieben von heiss
@ghostgambler

mysql_info und preg_split sind die kompaktesten, und übersichtlichsten Weisen genau das abzufragen was in der Logik von Frager ist. Sonst wird wegen einem kleinen Fehler die ganze Programmabschnittsstruktur über den Haufen geworfen. Es ist legitim zu schauen ob session-id getroffen wurde.

Es ist vom Sinn her vollkommen unnötig. Beim Session_Start wird der Datensatz ausgelesen, entweder ist er dann da, oder er wird angelegt. Bei einem Update existiert der Datensatz somit auf jeden Fall, sofern der Query keinen Error wirft, ist alles in Ordnung.
Wozu soll man also einen (aufwendigen) Pattern über den Output einer Funktion jagen, wenn die einfache Abfrage eines Integer Wertes zum gleichen Ergebnis führt?!

Eigentlich würde es noch besser und Datenbankschonender gehen: Man packt das, was beim Session-Start aus der DB geholt wird, in eine Variable der Klasse und bei einem Update wird verglichen, ob der neue String überhaupt anders ist als der alte, das spart Queries und ist für viel beschäftigte Datenbankserver die beste Variante.

[PHP-Desaster]

ja, das ist so nicht schlecht, nur wird sonst nirgends die zeit der session neu gesetzt!! also muss der query auf jedenfall raus!
es gibt einmal entweder daten holen oder neuen datensatz anlegen und dann aktualisieren!! da nach dem anlegen eines datensatzes sich der sessioninhalt bestimmt ändert, zwecks login etc. wäre die überprüfung überflüssig!! aber danke für die gute idee

[ghostgambler]

Original geschrieben von PHP-Desaster
ja, das ist so nicht schlecht, nur wird sonst nirgends die zeit der session neu gesetzt!! also muss der query auf jedenfall raus!
es gibt einmal entweder daten holen oder neuen datensatz anlegen und dann aktualisieren!! da nach dem anlegen eines datensatzes sich der sessioninhalt bestimmt ändert, zwecks login etc. wäre die überprüfung überflüssig!! aber danke für die gute idee

Muss man alles vorkauen? Oo,

if (!isset($_SESSION['time']) OR ($_SESSION['time'] + 60) < time()) { // 60 = eine Minute
  doQuery();
  $_SESSION['time'] = time();
} 

Das macht man z.B. auf alle 5 Minuten (+ (60*5)) (Queries sparen) und das "Problem" ist gelöst