In line with what Moke123 said, I would strongly recommend against using Date/Time Extended in practically any context:
1. Native Access calculation functions related to date/time don't work correctly with the format. You specifically state your purpose in converting to Date/Time is to enable date calculations, which will give flatly incorrect results using the date/time extended format in Access
2. Enabling and using the format completely prevents opening the database on older Access platforms
3. Even linking to tables (via e.g. ODBC) that include millisecond precision using date/time extended does not work properly and results in all records appearing as #Deleted in the relevant table (known bug).
4. You cannot create a Date/Time Extended data type field programmatically in Access. The support for it simply has not be implemented.
Overall, support and compatibility with the Date/Time Extended format is just severely lacking (incidentally, the same is true of the BigInt optional data type). There is a better solution... just store the Date/Time without milliseconds in a Date/Time field, and pull out the milliseconds into a separate field. Now native time calculations will work correctly, and if you need to care about e.g. the difference in time between two events in milliseconds, you can write custom function(s) as needed to accomplish that, something like:
Code:
Public Function DateDiffMs(ByVal StartDateTime As Date, ByVal EndDateTime As Date, ByVal StartMs As Integer, ByVal EndMs As Integer) As Long
Dim lSecondsDiff As Long, lMsDiff As Long
lSecondsDiff = DateDiff("s", StartDateTime, EndDateTime)
lMsDiff = lSecondsDiff * 1000
lMsDiff = lMsDiff + (EndMs - StartMs)
DateDiffMs = lMsDiff
End Function
I've attached another version of the project with implemented changes. TrimData now checks for values in format ####/##/## ##:##:##:###* and converts those into two fields as described above, one Date/Time field and one integer field containing the Ms part of the date/time.