In examples on an optimistic approach, @version (for example as parameter in procedures) is always in advance known.
Whether it is possible to receive @version in the procedure and on what it can affect.
Part of procedure:
CREATE PROCEDURE [dbo].[UpdateTestTable2]
...
SELECT @version = [version]
FROM dbo.TestTable2
WHERE Id = @Id
BEGIN TRANSACTION
UPDATE dbo.TestTable2
SET testName = @testName
WHERE Id = @Id AND [version] = @version
...
The “version” needs to come from the app and reflects the version of the record that has been selected for update. This information is then included as part of the update to ensure that one is updating the same version of the record that is being “viewed”.
This is what you seem to be doing by supplying some information from outside (in this case @id). But, as Igor points out, there is nothing magic about a column called “version”: you can drop your first select and leave the filter using @id.
But…what you are missing is a simultaneous update of the version/id field. You should do smoething like this:
that way, you are updating exactly the column you intend to, but at the same time are precluding anyone else from doing so by changing the version stamp.