转换“；dd/MM/yy hh:MM-tt”；字符串到日期时间”；yyyy-mm-dd hh:mm:ss.000”；并将

本文关键字：hh 时间 yyyy-mm-dd ss 并将 日期 mm MM-tt dd MM yy | 更新日期: 2023-09-27 18:22:11

我一直在使用DateTimes和SQL Server。

尽管我已经测试了转换，并确认它有效。

string date = "21/12/15 11:45 AM";
DateTime TempDate = DateTime.ParseExact(date, "dd/MM/yy hh:mm tt", CultureInfo.InvariantCulture);
Console.WriteLine(TempDate);
//Returns 2015.12.21. 11:45:00

当我将相同的逻辑应用于SQL时，它显示以下错误：

System.ArgumentException：无法转换为System.Int32。
参数名称：类型--->System.FormatException：输入字符串的格式不正确。

当我使用以下代码时

Command.Parameters.Add("@DateNext", SqlDbType.DateTime);
Command.Parameters["@DateNext"].Value = DateTime.ParseExact(SurDateNext, "dd/MM/yy hh:mm tt", CultureInfo.InvariantCulture);
//Where SurDateNext is the following string "21/12/15 11:45 AM"

我尝试插入值的字段是DateTime，默认格式为yyyy-mm-dd hh:mm:ss.000。

我到底做错了什么？

转换“；dd/MM/yy hh:MM-tt”；字符串到日期时间”；yyyy-mm-dd hh:mm:ss.000”；并将

正在运行的查询：
更新日期SET DateNow=CAST（'2015-12-21 11:45:00'AS DATETIME）WHERE ID='135'

该错误抱怨的是整数，而不是日期。我的猜测是，直到这个过程的后期，你才会看到异常，它实际上是在抱怨ID值，它似乎在不应该包含单引号的地方。

你想把代码结构得更像这样：

string sql = "UPDATE [Dates] SET DateNow= @DateNext WHERE ID= @ID ;";

如果您曾经看到原始数据值被替换到该查询中，那么您这样做是错误的！使用查询参数的全部意义在于，参数data是never包含在sql命令中，因此不可能向命令中注入恶意数据。

此外，您根本不应该担心Sql Server的日期时间值的格式。将日期字符串放入.Net DateTime变量中，使用带有DateTime参数的参数化查询，并将数据保存在Sql Server DateTime列中。让ADO.Net来处理剩下的部分。

您似乎认为Sql Server使用yyy-mm-dd hh:mm:ss.000格式存储日期，但这并不准确。Sql Server使用二进制（不可读）格式存储日期。它只是您的DB/查询工具，为方便起见，向您显示其他格式。

让我们把整个事情放在一起：

string SurDateNext = "21/12/15 11:45 AM";
string sql = "UPDATE [Dates] SET DateNow= @DateNext WHERE ID= @ID ;";
using (var cn = new SqlConnection("connection string here"))
using (var cmd = new SqlCommand(sql, cn))
{
    cmd.Parameters.Add("@DateNext", SqlDbType.DateTime).Value = DateTime.ParseExact(SurDateNext, "dd/MM/yy hh:mm tt", CultureInfo.InvariantCulture);
    cmd.Parameters.Add("@ID", SqlDbType.Int).Value = 135;
    cn.Open();
    cmd.ExecuteNonQuery();
}

给定一个有效的连接字符串和表定义，我向您保证代码会起作用。

如果您有该查询中包含的任何附加值，并且不使用查询参数，那么让我们先解决这个问题。然后确保DateTime.ParseExact()、Convert.ToInt32()和类似的代码都发生在它们自己的行上，这样您就可以遍历代码，找到导致错误的确切行以及值。

我将大胆地回答这个问题，因为我很确定我知道问题的根源。

海报显示正在使用内联SQL（参数化）。这也适用于存储过程。海报还指出，他/她的SQL中没有名为"type"的参数这表示问题嵌套在SQL语句中，并且在尝试调用内部或用户定义的SQL函数时会产生错误。示例：

UPDATE Employee SET EditedOn = CAST(@SomeDate as datetime)

如果@SomeDate不能强制转换为有效的日期时间，那么cast函数本身可能会出错。以下是一些旨在帮助解决问题的观察结果：

  • 如果不使用某种ORM，请使用存储过程。学习如何使用它只需要很短的时间，而且这笔小额的前期投资大约可以偿还1000倍，因为
  • 正如您所看到的，内联SQL使调试变得更加困难。当遇到解决方案不明显的任何类型的SQL错误时，我建议的第一件事是绕过C#，通过SQL Management Studio手动执行存储过程。这将立即告诉您问题是您的C#代码还是您的T-SQL
  • 尽可能使用正确的数据类型。不要将日期存储为nvarchar，或者在应该是日期时间时接受SQL参数作为nvarchar。这不仅使代码本身就不安全，容易出现错误，而且，当您开始处理越来越大的数据集时，对SQL数据执行函数可能是索引查找和表扫描的区别，因此（在严重情况下），存储过程的执行时间是毫秒，而不是小时。如果一个字段应该存储一个日期时间，那么将其设为日期时间。CAST和CONVERT应该在您拥有其模式的数据库中非常谨慎地使用
  • 最后，您可以（也应该）使用SQL探查器开始对数据库进行跟踪。然后您可以看到正在执行的EXACT查询。您可以将查询直接从Profiler复制/粘贴到SQLServerManagementStudio中，使用它直到它工作，然后修复C#代码
相关文章：