TImeStamp or not

[Lauren Quantrell]

Is there any reason to have a TimeStamp column onto a table that has a
PrimaryKey when using SQL Server and an Access front end?
I read that doing so will always eliminate that write conflict error.
But I notice that when pulling a recordset of 10K records, it takes 3X
less time if I delete the timestamp column on the table before running
the SP.
lq

[Simon Hayes]

"Lauren Quantrell" <la*************@hotmail.com> wrote in message
news:47**************************@posting.google.c om...

Is there any reason to have a TimeStamp column onto a table that has a
PrimaryKey when using SQL Server and an Access front end?
I read that doing so will always eliminate that write conflict error.
But I notice that when pulling a recordset of 10K records, it takes 3X
less time if I delete the timestamp column on the table before running
the SP.
lq

If you use a timestamp (rowversion) column, then your application has to do
something with it. If your application doesn't use it, then there's no point
in having it. I don't know much about Access, so perhaps there is some good
reason to always have one from an Access perspective, but you may want to
post to an Access newsgroup to clarify that.

Simon

[Jim Andersen]

Lauren Quantrell wrote:

Is there any reason to have a TimeStamp column onto a table that has a
PrimaryKey when using SQL Server and an Access front end?
I read that doing so will always eliminate that write conflict error.
Yup.
But I notice that when pulling a recordset of 10K records, it takes 3X
less time if I delete the timestamp column on the table before running
the SP.

An SP returns a read-only dataset. Never select a column thats not needed.

/jim