Verrechnet

[Steffen]

Hallo,

Hallo,

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.

Wieder was gelernt.

Eine gute Idee ist es, sprintf() zu verwenden, um sich die ständigen Zeichenkettenunterbrechungen und -verkettungen zu ersparen.

Verstehe nicht ganz, was Du meinst. Erklärst Du mir das mal?

Ich persönlich benötige Leerzeichen vor und nach den Operatoren, sonst kann ich Code nicht lesen.

das, was man nach mysql_query() *immer* tun sollte: eine Fehlerbehandlung durchführen. Nachschauen, was schiefgegangen ist und auf jeden Fall ins Anwendungsfehlerprotokoll schreiben.

Genau das mache ich auch. Aber ich werde nicht immer schlau daraus. Ich schreibe ins Fehlerprotokoll, bei welchem Seitenaufruf ein Fehler passiert ist. Leider fehlt mir dann aber die Query, bei der es passierte. Bisher ist es mir nicht gelungen, die Query an die Funktion zu übergeben, damit auch die eingetragen wird. Jeder Versuch endete damit, dass die Eintrag-Query einen Fehler verursachte, wenn sie die "Fehlerquery" einzutragen versucht hat.

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).

Auch so eine Geschichte. Ich mache das weitestgehend so, wie Du schreibst. Im Produktivbetrieb gebe ich keine mysql_error()-Fehlermeldungen, sondern nur eigene fehlermeldungen aus.
Leider habe ich noch keine gute Möglichkeit des schnellen Umschaltens zwischen Testbetrieb und Produktionsbetrieb gefunden (aber auch noch nicht wirklich danach gesucht).

Was heißt unique-Zufallswert? Wie sieht das aus? Kann es nicht sein, dass das UPDATE-Statement zufällig den gleichen Wert liefert?

Ich glaube, nicht.
unique-Zufallswert heißt, dass ich eigens einen Wert bestimme, der ganz sicher ein anderer ist, als der bereits in der Spalte eingetragene.
Klar, ich könnte die von php mitgelieferte Unique-ID nehmen, aber ich hatte hierfür schon eine Funktion, nämlich microtime().

Woher soll ich wissen, dass Du das weißt? Es ist ein offensichtlicher Fehler, ein Fehler, den ich schon oft gesehen habe.

Ich bin Dir doch auch dankbar für den hinweis, aber es muss doch erlaubt sein, darauf hinzuweisen, dass man dieses Problem schon eliminiert hat?

Protokolliere die SQL-Statements und protokolliere die MySQL-Fehlermeldungen

Wenn Du mir hierfür eine gute Arbeitsanleitung selber oder verlinkst geben kannst, wäre ich super dankbar! Das wäre wirklich ein Quantensprung für mich, denn bisher mache ich das zwar, aber es hilft mir nur bedingt, weil nur der Seitenaufruf mit Parametern gespeichert wird und das reicht nicht immer, um auch den Fehler zu finden.

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.

Natürlich. Steht schon auf meiner ToDo-Liste.

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.

Ok. Habe ich bisher keine Probleme mit gehabt. Werde ich aber mal im Hinterkopf behalten.

Grüße, Steffen