[SQL Server] Timestamps

[whoami]

Ik was net ff met SQL Server aan het spelen, en ik had volgende table aangemaakt:

tblUser
(
UserId INT autoinc,
UserName VARCHAR,
UserPwd VARCHAR,
UserEmail VARCHAR,
DateChanged TIMESTAMP
)

De bedoeling van de 'DateChanged' columns is dus, dat ik weet wanneer een record aangemaakt/geupdated werd, dit voor concurrency redenen.

Nu, heb ik een record als volgt geinserted:

code:

INSERT INTO tblUser
(UserName, UserPwd, UserEmail)
VALUES
('blaat', 'pass', 'blaat')

Ik ging erdus van uit dat het veld DateChanged op de systemdatetime ging staan van de server waarop het record gecreeërd werd.
Niets is echter minder waar. Als ik een select * deed, dan kreeg ik het volgende te zien:

1 blaat pass blaat 0x00000000000004BB

Ik vond het dus al vreemd dat ik die timestamp in een hex-formaat kreeg. Als ik die hex-waarde convert naar een datetime waarde, dan krijg ik volgende waarde:
1900-01-01 00:00:04.037

Dit is dus allesbehalve de systemdatetime.

gorgi_19 wees me toen op deze link, waarin afgeraden wordt om timestamp columns te gaan gebruiken. Echter, in die pagina staat wel een quote uit de BoL:

The SQL Server timestamp data type has nothing to do with times or dates. SQL Server timestamps are binary numbers that indicate the relative sequence in which data modifications took place in a database

Dus, eigenlijk is -als ik het goed interpreteer- die timestamp wel degelijk geschikt voor mijn situatie.

Heeft iemand een idee hoe het komt dat die timestamp waardes in hex-formaat getoond worden, en dat het niet de system-datetime is die gebruikt wordt?

Hoe houden jullie bij wanneer een record gemaakt/gewijzigd werd? Doen jullie het met een timestamp, of eerder met een datetime column die jullie dan zelf (in de stored procedure ofzo) gaan gaan updaten?

[Janoz]

Waarschijnlijk is ervoor gekozen om niet de tijd te nemen, maar gewoon een opeenvolgend nummer (of dit nu als hex, decimaal of getruft wordt weergegeven maakt eigenlijk geen drol uit). Zeker met concurency is dit een betere keus. Het zou best kunnen dat een bepaalde actie in dezelfde (mili)seconde gebeurt en daardoor dezelfde tijd krijgt. Met dit systeem weet je zeker dat het een uniek getal is.

[Verwijderd]

Ik leest net in de SQL Server help

Has a timestamp data type. The current timestamp value is used.

end

Forces SQL Server to load the default value defined for a column. If a default does not exist for the column and the column allows NULLs, NULL is inserted. For a column defined with the timestamp data type, the next timestamp value is inserted. DEFAULT is not valid for an identity column.

[whoami]

[nohtml]

Verwijderd schreef op 11 maart 2003 @ 13:17:

Has a timestamp data type. The current timestamp value is used.

Ja, maar wat is de current timestamp?
Ik bedoel, hoe wordt die dan bepaald?

[Dido]

SQL icm met DB2 accepteert als value idd CURRENT TIMESTAMP.

Hetgeen ervoor zorgt dat de "huidige tijd"wordt ingevoerd, de datum/tijd van wijzigen dus.

Zoiets dus:

code:

INSERT INTO tblUser
(UserName, UserPwd, UserEmail, DateChanged)
VALUES
('blaat', 'pass', 'blaat', CURRENT TIMESTAMP)

Wat doet dat bij jou?

[ Voor 68% gewijzigd door Dido op 11-03-2003 13:22 ]

[EfBe]

whoami schreef op 11 March 2003 @ 13:11:
Heeft iemand een idee hoe het komt dat die timestamp waardes in hex-formaat getoond worden, en dat het niet de system-datetime is die gebruikt wordt?

Timestamp zijn binary values. Dus hexadecimale waarden ligt voor de hand. Omdat t.a.t. de sequence in takt moet blijven is het gebruik van de systeemdatum niet geschikt: wanneer je op je systeem de datum (of tijd) terugzet, zou je je sequence beinvloeden, en dat wil je niet.

Hoe houden jullie bij wanneer een record gemaakt/gewijzigd werd? Doen jullie het met een timestamp, of eerder met een datetime column die jullie dan zelf (in de stored procedure ofzo) gaan gaan updaten?

Soms doe ik het met een GETDATE() value die ik insert in een datetime field, als ik puur een datum/tijd wil weten, of soms met een trigger.

Timestamp columns gebruik ik alleen in mn forum package, omdat SQLServer's full text search indexing de timestamp column gebruikt voor het bijhouden van changes in de full text indexed columns. Zodoende hoef je dus niets te doen om changes automatisch te laten opnemen in je word-catalog voor je text search

[whoami]

EfBe schreef op 11 March 2003 @ 13:43:

de sequence in takt moet blijven is het gebruik van de systeemdatum niet geschikt: wanneer je op je systeem de datum (of tijd) terugzet, zou je je sequence beinvloeden, en dat wil je niet.

Hmmm.... Daar had ik nog niet aan gedacht. Goed punt dit.

Soms doe ik het met een GETDATE() value die ik insert in een datetime field, als ik puur een datum/tijd wil weten, of soms met een trigger.

Timestamp columns gebruik ik alleen in mn forum package, omdat SQLServer's full text search indexing de timestamp column gebruikt voor het bijhouden van changes in de full text indexed columns. Zodoende hoef je dus niets te doen om changes automatisch te laten opnemen in je word-catalog voor je text search

Mooi.
Maar, waarom gebruik je dan geen timestamp veld in de andere situaties? Zoals ik het nu zie, biedt die timestamp enkel maar voordelen tov datetime columns.

[whoami]

Dido schreef op 11 March 2003 @ 13:19:
SQL icm met DB2 accepteert als value idd CURRENT TIMESTAMP.

Hetgeen ervoor zorgt dat de "huidige tijd"wordt ingevoerd, de datum/tijd van wijzigen dus.

Zoiets dus:

code:

INSERT INTO tblUser
(UserName, UserPwd, UserEmail, DateChanged)
VALUES
('blaat', 'pass', 'blaat', CURRENT TIMESTAMP)

Wat doet dat bij jou?

Een column met het type Timestamp in SQL Server aanvaardt geen default value.

[Dido]

whoami schreef op 11 maart 2003 @ 13:59:
Een column met het type Timestamp in SQL Server aanvaardt geen default value.

Is CURRENT TIMESTAMP een default value dan? Het is voor DB2/SQL een special register waar de timestamp staat die overeen komt met je huidige systeemwaarde en tijd...

Je systeemtijd veranderen doe je natuurlijk niet op een mainframe, dus dat probleem ben ik nog nooit tegen aangelopen

[whoami]

Als ik het volgende doe:

code:

INSERT INTO tblUser
(UserName , UserPwd, UserEmail, DateChanged)
VALUES
('blaat', 'blaat', 'blaat', getdate())

Dan krijg ik een error:

Disallowed implicit conversion from data type datetime to data type timestamp, table 'Organizer.dbo.tblTest', column 'changed'. Use the CONVERT function to run this query.

Echter, ik de timestamp wordt toch zowiezo door het DBMS opgevuld, dus dat is eigenlijk het probleem niet. Ik vroeg me gewoon af waarom ik een hex-waarde kreeg, en waarom die datetime-waarde niet de huidige systeemdatum is.
Ondertussen is EfBe al met een bevredigend antwoord gekomen.

[EfBe]

whoami schreef op 11 March 2003 @ 13:57:
Mooi.
Maar, waarom gebruik je dan geen timestamp veld in de andere situaties? Zoals ik het nu zie, biedt die timestamp enkel maar voordelen tov datetime columns.

Timestamps zijn voor sequential logging zaken. Als je gewoon wilt weten wanneer iets is gewijzigd, gebruik je een datetime field en zet je daar de value in die je terugkrijgt van GETDATE(). Is dus iets heel anders. Als je de volgorde van updates wilt bepalen, is een timestamp onontbeerlijk. Ook kun je timestamps opslaan en later checken of deze is gewijzigd. Dan kun je er t.a.t. vanuit gaan dat de row is gewijzigd. Die getdate() handel is puur voor reporting zaken, daar kun je verder uiteraard weinig logica aan verbinden.

[whoami]

EfBe schreef op 11 maart 2003 @ 14:42:
[...]

Timestamps zijn voor sequential logging zaken. Als je gewoon wilt weten wanneer iets is gewijzigd, gebruik je een datetime field en zet je daar de value in die je terugkrijgt van GETDATE(). Is dus iets heel anders. Als je de volgorde van updates wilt bepalen, is een timestamp onontbeerlijk. Ook kun je timestamps opslaan en later checken of deze is gewijzigd. Dan kun je er t.a.t. vanuit gaan dat de row is gewijzigd. Die getdate() handel is puur voor reporting zaken, daar kun je verder uiteraard weinig logica aan verbinden.

Hmmm, ok.
Mijn bedoeling was om iets in te bouwen ivm concurrency. (Weten of een record ondertussen gewijzigd werd door een andere user). Voor dit is een timestamp dan dus beter.

Thx all.