Skip to content
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

Closed
dev-ska opened this issue Feb 18, 2020 · 6 comments

Comments

@dev-ska
Copy link

dev-ska commented Feb 18, 2020

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:

CREATE TABLE SqlClientTest
(
	DateTimeColumn datetime2 NOT NULL
)
GO

Code:

using (var connection = new SqlConnection(connectionString))
{
	var command = new SqlCommand($"insert into SqlClientTest (DateTimeColumn) values (@value)", connection);
	var parameter = command.CreateParameter();

	parameter.ParameterName = "@value";
	parameter.Value = DateTime.Now;
	parameter.DbType = DbType.Date;

	command.Parameters.Add(parameter);

	connection.Open();
	command.ExecuteNonQuery(); // running on v1.1, DateTimeColumn has no time part
	connection.Close();
}

Was this a functional change?

@ErikEJ
Copy link
Contributor

ErikEJ commented Feb 18, 2020

Yes, I believe so: #269

@dev-ska
Copy link
Author

dev-ska commented Feb 19, 2020

@ErikEJ Thanks!

@dev-ska dev-ska closed this as completed Feb 19, 2020
@cheenamalhotra
Copy link
Member

@dev-ska

Since you're specifying "parameter.DbType = DbType.Date;" you're seeing this difference.
You need to specify "parameter.DbType = DbType.DateTime" in order to receive the time part.

@dev-ska
Copy link
Author

dev-ska commented Feb 20, 2020

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.

@ErikEJ
Copy link
Contributor

ErikEJ commented Feb 20, 2020

Hmm.. So a breaking change caused by a wrong mapping (bug) in your code.

@dev-ska
Copy link
Author

dev-ska commented Feb 21, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants