Update auf Timestamp-Colum

[hbspike]

Hallo zusammen.

Ich habe da ein etwas komisches Problem, was ich nicht ganz nachvollziehen kann.

Ich habe eine "Nachrichten"-Tabelle mit 2 Timestamp-Columns. Einmal

nachrichten_recieve_timestamp und

nachrichten_read_timestamp

Nun bin ich soweit das ich Nachrichten zwischen Usern hin- und herschicken kann. Sie lesen und löschen kann.

Das Problem nun ist, das ich gerne einen "gelesen"-Zeitstempel incl. Statusänderung realisieren will.

Beim anschauen einer Nachricht, soll der "nachrichten_read_timestamp" wenn noch nicht vorhanden auf den aktuellen Timestamp gesetzt werden.

Mein SQL-Statement hierfür :

UPDATE Nachrichten set nachrichten_status=1,nachrichten_read_timestamp='2012-12-03 09:47:34.761' WHERE nachrichten_id=46

Mein eigentliches Problem ist nun, das sowohl nachrichten_read_timestamp als auch nachrichten_recieve_timestamp auf den aktuellen Timestamp gesetzt wird. Warum passiert das? Hat da wer eine Idee? Mfg Chris Edit: Meine Tabellendefinition:

create table Nachrichten (

  nachrichten_id                int(10) not null auto_increment, 

  nachrichten_sender            int(10) not null, 

  nachrichten_betreff           int(10) not null, 

  nachrichten_status            int(10) default 0 not null, 

  FK_postkorb_id                int(10) not null, 

  nachrichten_empfaenger        int(10) not null, 

  nachrichten_recieve_timestamp timestamp not null, 

  nachrichten_read_timestamp    timestamp null, 

  nachrichten_content           longtext not null, 

  primary key (nachrichten_id), 

  unique index (nachrichten_id), 

  index (nachrichten_sender)) CHARACTER SET UTF8; 

Bearbeitet 3. Dezember 2012 von hbspike

[Klotzkopp]

Mein eigentliches Problem ist nun, das sowohl nachrichten_read_timestamp als auch nachrichten_recieve_timestamp auf den aktuellen Timestamp gesetzt wird.

Auf genau diesen? Einschließlich Millisekunden?

Ist da irgendein Trigger am Werk?

[hbspike]

Kann geschlossen werden.

Lag am "not null" der nachrichten_recieve_timestamp - Spalte.

[Daij]

Wie soll das funktionieren? Bzw. aus welchem Grund sollte das so sein?

Ich vermute auch eher, dass da im Hintergrund ein Trigger mit läuft, ein klar definiertes Update auf eine Spalte setzt ja keine andere Spalte mit um - und wenn du den Datensatz bereits angelegt hast ist dein receive Timestamp ja schon "NOT NULL" und dementsprechend die Bedingung erfüllt (sonst hättest du den Datensatz ja gar nicht anlegen können)

Deine Aussage erscheint also nicht korrekt.

[streffin]

Warum Timestamp ?

Für mich liest sich das als wolltest du da ein Datum, nicht einen Timestamp.

Ein Timestamp ist ein 8 Byte Hex value. Das wird / wurde oft für row-versioning benutzt wie man das bei Datawarehouse und replications braucht (heute würde man da ROWVERSION benutzen, alles andere ist legacy code). Wenn es dir um ein wirkliches Datum geht, nimm lieber datetime oder datetime2. (Datetime2 ist schlicht genauer als Datetime)

Damit sparst du dir viele eventuell später aufkommende Probleme.

[dr.dimitri]

Das wird / wurde oft für row-versioning benutzt wie man das bei Datawarehouse und replications braucht (heute würde man da ROWVERSION benutzen, alles andere ist legacy code).

Nur, wenn man in einer perfekten Welt lebt, und davon ausgeht, dass man niemals den Server wechselt, niemals restoren muss, niemals die DB wechselt...

Legacy code...

Dim