What will I get by adding a timestamp column called recordversion to the table in ms-sql?
You can use this column to ensure that your users are not overwriting data from another user.
Suppose user A has checked out record 1 and at the same time user B has checked out record 1. User A edits the record and saves it. After 5 minutes, user B is editing the record, but is unaware of the changes made by user A. When he saves his changes, you are using the recordversion column in your update, where a condition that will prevent user B from overwriting what user A did. You may find this invalid condition and throw some stale data error.
source to share
Nothing I know, or that Google seems to find quickly.
You can get something of your own by using this column name. Of course, you can create a column and do record versioning as described in the next answer, but there is nothing special about the column name. You can call any column, whatever, and do versioning, and you can call any column, RecordVersion, and nothing special happens.
source to share
Also keep in mind, if you want to track your data, it is recommended that you add these four columns to each table:
CreatedBy(varchar) | CreatedOn(date) | ModifiedBy(varchar) | ModifiedOn(date)
While it doesn't give you the full history, it lets you know who created the record and when, and who last modified it and when. These 4 columns create some pretty powerful tracking capabilities without any major overhead for your database.
Obviously, you could create a full blown logging system that tracks every change and gives you a complete history, but this is not a solution to the problem I think you are proposing.
source to share
The timestamp is primarily used for replication. I also used this successfully to determine if the data has been updated since the last feed to the client (when I needed to send a delta stream) and thus only select the records that have changed since then. This requires that there is another table that stores the timestamp values (in the varbinary field) at the time the report is run, so you can use it for comparison in the next run.
If you think the timestamp records the date or time of the last update, it doesn't, you need date and time fields and constraints (to get the original time and time) and triggers (to update) to store that information.
source to share