>Aaron,

(later update)
>Transformation is easy, from shortdatetime to datetime... I would think it is pointless to mention... If the Year 2076 is material risk at the time comes, a simple table design change would finish the job easily.

The data column change itself is fairly trivial. The vast majority of the manhours spent on the Y2K problem was spent finding what needed to be changed, making the code/gui changes and the testing of those changes.

>>I'm not being naive, but it is reality... AND I hate those database programmers being so ignored about the real world, setting a surname field to C(255)... and so... making each record to be 5K-6K large...
>
>Bad design is bad design whereever it occurs.
>
>>David, you should think in wider propectives...
>
>That's exactly what I'm doing.
>
>>Todays, everything come and go via connections...
>
>If you don't need the time portion sent across the wire, use a view that trims it off. The year span being greater is more important than the time potion in most cases.