Linq to sql 时间戳列始终返回
我有一个 DBML，其中一个类包含 sql 中的时间戳列。
DBML中的属性声明为：（仅此处指定的相关字段）
自动生成值：true 名称：时间戳 可空：假 服务器数据类型：rowversion NOT NULL 来源：时间戳 时间戳：true 类型：二进制 更新检查：从不
按照我的逻辑，我插入到这个表中。然而，我惊讶地发现生成的 sql 看起来像这样：
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 */
我想摆脱该 SELECT 语句 - 我不使用结果。
这是否可能，或者是否强制要求对于对象跟踪，数据上下文必须知道该新记录的时间戳是什么？
我认识到我可以改用 SP 作为插入方法，但我更愿意避免这种情况。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要额外的 select 来更新对象的本地实例在任何后续更新/删除子句的并发检查中更新自身时使用的时间戳。由于每次更改/插入行时都会更新 RowVersion (TimeStamp) 值，因此客户端需要新版本，否则后续更新将失败，因为时间戳值将不再相同。
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.