Built-in version columns appeared many years ago to simplify automatic version change in manually written SQL, but now we have a bit different case. Imagine:

• They invented a special data type for this! // Why? And why just one?

• You actually don't have much control of the provided behavior

• In many cases there is no necessity for an additional column (e.g. for m-n relationship tables). They can't help here at all.

• The same idea is implemented differently in almost any database - that's bad.

• Finally, it's necessary to read the new value of such version after update. In our case it's simply known.

So for me this is nearly the same case as stored procedures or triggers: they appeared to solve the problem, that doesn't exist, if there is an ORM + solid BLL framework. Or, more precisely, exists, but it's much easier and convenient to solve it @ higher level now.

Although we must anyway think about supporting such versions in Legacy mode.