C# WinForms使用ListBox按日期筛选DataGridView报日期转换错误问题咨询

云上老周

2026-11-2

核心报错根因

Conversion failed when converting date and/or time from character string的触发逻辑非常明确：

从SQL Server读出来的date类型列，本身是无格式的二进制日期值。你把它直接Add到ListBox时，C#会自动调用该值的ToString()方法，输出格式完全适配当前WinForm运行环境的系统区域设置——你看到的dd/mm/yyyy显示效果，就是这个本地化转换的结果，这个生成的字符串对SQL Server来说没有稳定的解析规则。
你将ListBox选中的内容直接硬拼到筛选用的SQL语句中时，SQL Server会按照自身会话配置的默认日期解析规则（多为月/日/年或年-月-日格式）尝试解析这个dd/mm/yyyy格式的字符串，一旦字符串中的“日”部分数值大于12，解析逻辑直接崩溃触发报错。

你之前纠结的两个方案的问题

完全不需要在Excel导入SQL Server的阶段调整日期格式：SQL Server的date类型不存储任何展示格式，不管导入时Excel的日期是什么显示格式，最终落入列的都是无格式的纯日期值，调整导入环节的格式设置对后续的报错没有任何帮助。
不推荐将SQL中的date类型转成固定格式字符串、再在WinForm端做字符串匹配：这种做法会彻底丢失日期类型原生支持的范围查询、排序能力，还会因为多环境下的格式差异出现匹配漏数、错位的问题，排查成本极高。

正确解决思路

整个流程要守住日期值全程强类型传递、不拿本地化生成的字符串做跨层匹配的核心原则，具体实现分三步：

调整ListBox的条目存储结构，不要直接把日期值塞进Items集合
不要直接把SqlDataReader读出来的日期值Add到ListBox中，而是给每个条目拆分两个独立属性：

面向用户的展示文本：手动指定为dd/mm/yyyy格式，和你之前的显示效果完全一致
面向业务逻辑的隐藏值：存储原始的DateTime类型值，不受展示格式影响
参考实现代码：

// 轻量条目类，用于区分展示文本和实际值
public class DateDisplayItem
{
    public string DisplayText { get; set; }
    public DateTime ActualValue { get; set; }
    // 重写ToString，让ListBox自动展示时读取指定的展示文本
    public override string ToString() => DisplayText;
}

// 原读取数据代码的调整写法
SqlCommand cmd = new SqlCommand(sqlStr, conn);
SqlDataReader rd = cmd.ExecuteReader();
while (rd.Read())
{
    DateTime rawDate = rd.GetDateTime(0);
    mylistbox.Items.Add(new DateDisplayItem()
    {
        // 手动指定展示格式，不依赖系统自动转换
        DisplayText = rawDate.ToString("dd/MM/yyyy"),
        ActualValue = rawDate
    });
}

筛选逻辑改用参数化查询，不要硬拼字符串
用户选中ListBox条目后，直接取选中条目里的隐藏DateTime实际值，通过SQL参数传递给查询逻辑，不要把展示文本拼进SQL语句：

// 触发报错的错误写法
// string sql = $"SELECT * FROM TableName WHERE SettlementDate = '{mylistbox.SelectedItem}'";

// 无转换风险的正确写法
var selectedDateItem = mylistbox.SelectedItem as DateDisplayItem;
string sql = "SELECT * FROM TableName WHERE SettlementDate = @SettleDate";
SqlCommand filterCmd = new SqlCommand(sql, conn);
// 直接传入强类型的日期值，不需要做字符串转换
filterCmd.Parameters.AddWithValue("@SettleDate", selectedDateItem.ActualValue);

这种写法从根源上消除了转换问题
从ListBox选中到SQL查询传参的全流程，日期都是以强类型的DateTime值传递，没有经过任何受区域设置、系统配置影响的字符串转换环节，SQL Server拿到的是明确的日期类型参数，根本不需要做字符串转日期的解析，自然不会触发转换失败的报错。

常见避坑提示

不要依赖ListBox自动生成的ToString()展示文本做任何业务逻辑判断：这个自动生成的格式完全跟随运行设备的系统区域设置变化，换个地区的设备运行时，日期格式可能直接变成mm/dd/yyyy，会重新触发同类转换问题。
不要为了适配dd/mm/yyyy格式去修改SQL Server的全局会话日期规则（比如执行SET DATEFORMAT dmy）：这种全局修改会影响同会话下所有查询的日期解析逻辑，很容易引发其他业务的查询错误，属于治标不治本的方案。

内容的提问来源于stack exchange，提问作者Pierre_CM