nicht angemeldet
Hallo,
Ich gehe davon aus, dass Dein Produktivcode anders aussieht.
Sicher sieht er das. Ich fand es eine gute Idee, eine Essenz aus dem Code zu zitieren, gebe aber zu, dass mir dabei kleine Fehler unterlaufen sind.
Es ist keine gute Idee, Code zu posten, der fehlerhaft ist.
Es ist keine gute Idee, Code zu posten, der bereits auf den ersten Blick Möglichkeiten für das beschriebene Problem aufweist, die im Produktionscode nicht vorhanden sind.
Ich korrigiere als erstes die Anführungszeichen:
Die sind im Produktivcode einmal escaped, insofern quasi identisch zu Deiner Korrektur.
Doppelte Anführungszeichen für Zeichenkettenliterale in SQL-Anweisungen sind in aller Regel keine gute Idee. Einfache Anführungszeichen werden immer akzeptiert, doppelte nur von wenigen DBMS und auch nur in bestimmter Konfiguration. Zusätzlich ist es viel angenehmer, keine Escape-Orgien feiern zu müssen.
Eine gute Idee ist es, sprintf() zu verwenden, um sich die ständigen Zeichenkettenunterbrechungen und -verkettungen zu ersparen. Ich persönlich benötige Leerzeichen vor und nach den Operatoren, sonst kann ich Code nicht lesen.
last_update = '" . time() . "', -- hier ist ein Komma zuviel
Klar. Hab ich vergessen, wegzunehmen. Im Produktivcode werden mehrere Spalten upgedatet, daher kommt das Komma.
Ja eben. Der gepostete Code führt garantiert zu einem Fehlschlagen von mysql_query() wegen eines SQL-Syntaxfehlers. Auf diesen muss ich hinweisen - *ich* weiß schließlich nicht, wie der Code im Original aussieht. Wenn man kürzt, dann muss man sorgfältig kürzen.
Wenn aus irgendeinem Grund mysql_query() fehlschlägt, was immer mal passieren kann,
Ist das wahr? Ok, das hätte ich einfach nicht gedacht. Was ist hieraus die sinnvolle Konsequenz für meinen Code?
das, was man nach mysql_query() *immer* tun sollte: eine Fehlerbehandlung durchführen. Nachschauen, was schiefgegangen ist und auf jeden Fall ins Anwendungsfehlerprotokoll schreiben. mysql_error() hilft dabei. Beim Entwickeln kannst Du die Fehlermeldung ausgeben - in der Produktion hat die Browserausgabe von mysql_error()-Meldungen nichts verloren (auch wenn man's häufig sieht).
Ohne den Hinweis aus der Doku gekannt zu haben, war ich mir dieser Tatsache schon bewußt. Deshalb habe ich eine Spalte mit einem unique Zufallswert, der ebenfalls innerhalb obiger Query upgedatet wird, sodaß ich dieses Problem behoben haben sollte.
Was heißt unique-Zufallswert? Wie sieht das aus? Kann es nicht sein, dass das UPDATE-Statement zufällig den gleichen Wert liefert?
Woher soll ich wissen, dass Du das weißt? Es ist ein offensichtlicher Fehler, ein Fehler, den ich schon oft gesehen habe.
Heißt im Umkehrschluss, dass gem. Deiner Hinweise eingentlich nur noch ein Fehlschlagen der Query für einen ungewollten User-Logout in Frage kommt?
Protokolliere die SQL-Statements und protokolliere die MySQL-Fehlermeldungen
Ach so: Selbstverständlich halte ich es für einen Designfehler, in einer DB-Tabelle für Zeitstempel Integerwerte zu verwenden statt des angemessenen Datentyps TIMESTAMP. Du hast es viel leichter beim Vergleich und kannst die eingebaute Magie dieses Datentyps nutzen.
Was könnte noch schiefgehen: die Session könnte beendet werden, weil in einer Shared-Hosting-Umgebung ein Fremdaufräumen passieren kann, siehe dazu </archiv/2010/2/t195076/#m1305347>ff.
Freundliche Grüße
Vinzenz