Avatar of NNOAM1
Flag for Israel

asked on 

When is it recommended to add a timestamp (/rowversion) field to SQL tables?

Hello everyone.
When "upsizing" an Access application to SQL Server, the Upsizing Wizard offers the possibility concerning adding timestamp field to the tables: "Let system decide". Likewise, SSMA offers the same possibility: "Let SSMA decide". I'd like to ask: how exactly they "decide" about which table "needs" a timestamp field and which doesn't?
The result of such operations is that some of the tables get timestamps and some of them don't. But I couldn't tell how that decision was "taken".
First I thought that small tables (in the sense of the amount of fields they have) don't get timestamp field and big tables do, but then I noticed some small tables that got timestamp by SSMA, and some big ones that didn't. So what is the consideration that SSMA takes when making that "decision"? And when I want to make that decision myself, without SSMA or the Upsizing Wizard, what is the best practice? In other words: When is it recommended to add a timestamp (/rowversion) field to SQL tables? (Assume that it's going to be used as linked tables to MS Access in a multi-user environment, which demands to take good care of concurrency)... I was thinking it to be good practice to add rowversion to all tables. Or isn't it?
Thank you.
Microsoft AccessMicrosoft SQL ServerSQL* rowversion/timestamp

Avatar of undefined
Last Comment
DatabaseMX (Joe Anderson - Former Microsoft Access MVP)

8/22/2022 - Mon