mysql timestamp?

timestamp ändras varjegång tabellen uppdateras. ("stämplar" tiden )

om du vi lägga till datum och/eller tid så är det det date som gäller..

som sagt, detta är sättet som TIMESTAMP funkar på.

Beroende på hur du har lagt upp det, så borde det ju räcka att du ändra ditt TIMESTAMP fält till DATE. Då ändras den inte varje gång du uppdaterar. och dom values du har lagt till (bör) förbli som dom var innan.

När du vill lägga till den så får du ju sätta den till NOW(), detta kan du ju släppa om du sätter defaulten på DATE till NOW.

Bra idé, men MySQL stödjer inte att använda värden från funktionsanrop som default-värden. Man kan ange strängvärdet "NOW()" som default för en date-kolumn, men det som då händer är att MySQL vid varje INSERT smygkonverterar den ogiltiga datumangivelsen (strängen "NOW()") till något den finner mer passande. För DATE blir det bara "000000".

Däremot kan man ange "NOW()" (eller valfri annan sträng, man kan skriva nästan vad som helst bara det inte tolkas som en datumangivelse) som default för en timestamp. Då får man "rätt" värden, men det beror på att MySQL:s bisarra första-timestamp-regel (som hallgren råkat ut för) har företräde framför DEFAULT-värden. Har man fler än en timestamp så används default-värdet i stället, vilket innebär att resterande kolumner får värdet "00000000000000".

Timestamp är en intressant funktion i mysql. Du får ett unixtimestamp oavsett hur många tecken du definierar ditt timestamp till att vara.

Säg att du säger att timestampkolumnen är 8 tecken lång. Då kommer ett datum i formatet ååååmmdd returneras. Definierar du det till 10 tecken får du åååå-mm-dd.

Ok, so what säger ni? Det allra tuffaste, och mest praktiska, är att oavsett vilken längd man definierar som så sparas _hela_ timestampet. Det innebär att man på en senare tidspunkt kan ändra definitionen på sin kolumn ifall man ändrar sig och vill visa till exempel klockslag också!

Ditt problem? Well, ful lösning men det är bara den första timestampkolumnen som auto-uppdateras. Så vill du komma från detta och fortfarande använda timestamp och inte date så kan du lägga till en extra "dummy-timestampkolumn" innan den du faktiskt använder dig av.

Skönt att ha rett ut det här.. har inte riktigt behövt ordna ut timestampfunktionaliteten förrän nu...

Till nästan alla tabeller finns nu 2 fält

date_created - DATETIME
date_modified - TIMESTAMP(14)

modified uppdateras varje gång man gör en update/insert och date_created får man sätta till NOW() vid en insert... så, då fungerar allt som tänkt

coolers.

Hehe - kul att vara till hjälp...

Hmmm sista jag bråkade med TIMESTAMP fick jag lära mig att det inte är ett äkta UNIX timestamp...
Ett äkta UNIX timestamp visar antalet sekuner som förflutit sedan 1970 eller nåt.

Mig veterligen ändras bara det SISTA TIMESTAMP:et i en tabell.
Så du kan lösa det genom att skapa två i slutet av varje tabell som du matar in ett TIMESTAMP i.

createTS, TIMESTAMP(!14)
editTS, TIMESTAMP(14)

Så ser alla mina tabeller ut i slutet, då vet jag när posten skapades och när den senast ändrades.

Si!

(12345 för att kunna posta...)

ALERT!!

Det är det första timestamp'et som ändras...

och nej, det är inget äkta unix-timestamp vad jag vet heller.. därför skriver du
SELECT UNIX_TIMESTAMP(date_modified) AS date_modified
FROM .....

Precis som Ivar säger, och jag skrev ovan, är det bara det första som updateras. De andra måste man sätta själv. Det är inget UNIX-timestamp heller, men det har andra, trevliga egenskaper som t ex att hela datumet lagras oberoende av vilken längd man sätter på sitt fält. Ändrar man längden på fältet i efterhand, finns all timestamp-data kvar; den har bara inte visats.