Datetime2 support
Brought to you by:
ickzon
SQL server 2008 adds the datatype datetime2.
jTDS currently returns these as a String from a query when they should be java.sql.Date
For insert / update jTDS seems to apply the 3ms rounding as per a datetime, which is unnecessary and unwanted for datetime2.
We have some unit tests to test datetime2 support. They need to be tidied up and have dependencies removed, but I can supply them if desired.
Anonymous
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Hi. I ran acroos the same problem of the rounding in the jTDS driver. The rounding seems to appear in DateTime#pack (Line 332).
In my opinion it is not necassary to round the date at this point (at least for MSSQL 2008) since it will do it itself if necassary:
select CAST('2007-05-08 12:35:29.125' AS datetime2);
Result: 2007-05-08 12:35:29.1250000
--
select CAST('2007-05-08 12:35:29.125' AS datetime);
Result: 2007-05-08 12:35:29.12
Best Regards, Torsten
3ms rounding also being applied in v1.2.6
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
issue remains in v1.2.8
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
This would be great to have. I think the format has been cracked here: http://sqlfascination.com/2009/10/11/what-is-the-sql-server-2008-datetime2-internal-structure/
I had a quick look at implementing this but it turns out there's a lot more to it than just the revised datetime2 storage format. The two most obvious problems are:
1. It requires supporting the TDS 7.3 protocol. The only reason datetime2 works at all at the moment is because SQL server detects the older client and converts to datetime wire format.
2. There doesn't appear to be a clean way for the jTDS driver to know whether the native storage is datetime or datetime2. Maybe this can be resolved using a proprietary jdbc escape sequence, e.g. {dt ?} which when parsed sets the pi.scale appropriately which can be used later to differentiate the data type.
So I think this is going to require one of the core devs to resolve, not just a nosey parker like me.
The issue remains in v1.3.1.
Would be really great to have this resolved.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
+1 on a request to get this issue resolved. Lack of this support has forced us to go back to using datetime on our deployment as a workaround for now.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Same here. Would like to request a fix.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
+1 on request for resolution
+1 on request for resolution
+1 on request for resolution
+1 on request for resolution
+1 on request for resolution
+1 on request for resolution