Bug #91770 | TIME(n) column loses microseconds with prepared command | ||
---|---|---|---|
Submitted: | 24 Jul 2018 4:40 | Modified: | 20 Apr 2020 15:53 |
Reporter: | Bradley Grainger (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / NET | Severity: | S2 (Serious) |
Version: | 8.0.11 | OS: | Windows (10) |
Assigned to: | CPU Architecture: | Any (x64) |
[24 Jul 2018 4:40]
Bradley Grainger
[24 Jul 2018 4:54]
Chiranjeevi Battula
Hello Bradley Grainger, Thank you for the bug report and test case. Verified this behavior on Visual Studio 2017 (C#.Net) and Connector/NET 8.0.11 version. Thanks, Chiranjeevi.
[24 Jul 2018 5:02]
Chiranjeevi Battula
Screenshot
Attachment: Bug_91770.PNG (image/png, text), 69.86 KiB.
[16 Apr 2020 19:45]
Gustavo Cuatepotzo
Posted by developer: The problem was in file MySqlTime.cs, the method ReadValue always divide the milliseconds by 1000000, this produce a decimal result, after, the result was cast to integer, that's why zero was returned.
[20 Apr 2020 15:53]
Christine Cole
Posted by developer: Fixed as of the upcoming MySQL Connector/NET 8.0.21 release, and here's the proposed changelog entry from the documentation team: The microseconds value in the return results was set to zero consistently when SqlCommand.Prepare() was called for a SELECT statement with a TIME(n) column. This fix revises the way the value is produced to ensure accurate results. Thank you for the bug report.