CODEWITHSUNDEEP
linq-to-sql
Nik
Nik

Reputation: 2726

Linq to sql timestamp column always returned

I have a DBML with a class that contains a timestamp column in sql.

The property in the DBML is declared as: (only relevant fields specified here)

Auto generated value:true Name: timestamp Nullable: false Server data type: rowversion NOT NULL Source: Timestamp Time Stamp:true Type: binary Update check:never

In my logic, I insert into this table. However, I'm surprised to see that the generated sql looks something like this:

exec sp_executesql N'INSERT INTO [dbo].Foo( /* elided */)
VALUES (@p0, @p1, @p2, @p3, @p4, @p5, @p6, @p7, @p8, @p9, @p10, @p11, @p12, @p13, @p14, @p15, @p16, @p17, @p18, @p19, @p20, @p21, @p22, @p23, @p24, @p25)

SELECT [t0].[Timestamp]
FROM [dbo].[Foo] AS [t0]
WHERE [t0].[Id] = @p26', /* elided */

I'd like to get rid of that SELECT statement - I don't use the result.

Is that possible, or is it mandated that for object tracking the datacontext must know what the timestamp was of that new record?

I recognise that I could switch to using an SP for the insert method, but would prefer to avoid that.

Upvotes: 0

Views: 504

Answers (1)

Jim Wooley
Jim Wooley

Reputation: 10398

The additional select is required to update the timestamp that the local instance of the object uses when updating itself in the concurrency check for any subsequent update/delete clauses. Since the RowVersion (TimeStamp) value is updated everytime the row is changed/inserted, the client needs the new version, otherwise a subsequent update would fail because the timestamp value would no longer be the same.

Upvotes: 1

Related Questions