-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change in handling of Date/DateTime values after migration from v1.0.19269.1 to v1.1.1. #434
Comments
Yes, I believe so: #269 |
@ErikEJ Thanks! |
Since you're specifying "parameter.DbType = DbType.Date;" you're seeing this difference. |
Thanks, it's understandable. The question was raised when the code (with an old history) successfully storing datetime's using SqlType.Date started to fail after switching to the new package version. |
Hmm.. So a breaking change caused by a wrong mapping (bug) in your code. |
Yes, I'm unsure about the original reason for mapping date times to DbType.Date. Might be something related to that the code should support SQL and Oracle databases. I've switched to the DbType.DateTime mapping and it works as it used to with SQL. But this is a subject for further investigation on how the oracle provider behaves with the mapping update. The eventual goal is to keep the previous behaviour on both database types. |
On v1.0: the DbType.Date parameter, which has a DateTime value, is saved as a DateTime in the database.
On v1.1: the DbType.Date parameter, which has a DateTime value, is saved as a Date in the database (a time part is truncated).
The database column is of type datetime2.
Table declaration:
Code:
Was this a functional change?
The text was updated successfully, but these errors were encountered: