>>>>Let me ask this - since you elected to go with the more precise datetime2 (down to nanosecond), is there an argument to be made that you're losing a tiny level of precision by assigning the mod date in the application layer with the VB DateTime.Now?
>>>
>>>It is for a single file that I am analyzing the log based on some isolated data gathering I wanted to log very fast. I am the only one analyzing it. So, when I went into SSMS, I was able to change the order by primary key to get that in the order it was created. The primary key will always be unique where the ModDate was not in that case as I was inserting records too fast.
>>>
>>>But, I wanted to open the door about the possibility of enhancing all those DateTime to DateTime2. But, for that, this requires some fine tuning in the code. There is also no guarantee that this would be able to accomplish if we switch into another development environment. But, as time goes by, such support would be better supported as is.
>>
>>I haven't followed this whole thread but given that the accuracy of DateTime.Now is probably about 10-15ms there doesn't seem much point in recording the value using a higher precision ?
>
>counters with higher precision exist...

Stopwatch on my machine reports a resolution of ~500 nanoseconds per tick - but I've a feeling that Michel may not be able to use a Stopwatch for his requirements ?