|
|
Posted by Dan Guzman on 10/08/05 16:34
> A timestamp is, of course, useful as a "last modified date/time" indicator
> for your applications, though.
Laurenq referred to the timestamp *data type* in his post. The timestamp
data type is a misnomer because it is not related to date or time. The
system-generated timestamp is simply an 8 byte binary value that is
guaranteed to be unique within a database that is updated automatically
whenever any data in the row changes. Consequently, the primary purpose of
timestamp is for optimistic concurrency checks to see if the row was updated
by another user. For example:
UPDATE MyTable
SET
SomeColumn1 = @SomeValue1,
SomeColumn2 = @SomeValue2,
SomeColumn3 = @SomeValue3
WHERE
MyPK = @MyPK AND
MyTimestamp = @OriginalMyTimestamp
IF @@ROWCOUNT = 0
BEGIN
RAISERROR ('Data was updated or deleted by another user', 16, 1)
END
--
Hope this helps.
Dan Guzman
SQL Server MVP
"David Cartwright" <dscartwright@hotmail.com> wrote in message
news:di8842$pq7$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
> "laurenq uantrell" <laurenquantrell@hotmail.com> wrote in message
> news:1128703331.710695.156120@f14g2000cwb.googlegroups.com...
>> Is there any reason to have a row that is the PK/Identity and a row
>> that is datatype Timestamp in the same table?
>> Does this in any way help speeding up row updates?
>
> Can't see that adding a timestamp field would speed anything up - in fact
> the presence of a field that is auto-populated means that, by definition,
> every time you INSERT or UPDATE the row, it'll have to do some work
> writing the current date and time to the table.
>
> A timestamp is, of course, useful as a "last modified date/time" indicator
> for your applications, though.
>
> D.
>
>
Navigation:
[Reply to this message]
|