看起来你在.NET Framework 4.8的集成测试场景里，为了处理遗留代码对用户语言敏感的日期格式问题，在切换SQL Server用户语言时遇到了两头堵的麻烦——直接用SET LANGUAGE不生效，改用户默认语言又触发登录错误，确实挺头疼的。咱们一步步拆解问题，看看可行的解决思路：

一、为什么SET LANGUAGE可能不生效？ #

我遇到过类似的遗留系统问题，常见的原因有这几个：

• 会话作用域没覆盖到实际业务查询：SET LANGUAGE是会话级别的设置，只对当前数据库连接生效。如果你的测试代码里，执行SET LANGUAGE的连接和后续执行业务查询的不是同一个（比如连接池复用了旧连接，或者ORM框架自动创建了新连接），那这个设置就不会起作用。
• 执行时机不对：如果是在事务中间执行SET LANGUAGE，但遗留代码里某些查询逻辑可能在执行前又重置了会话设置；或者你执行完SET LANGUAGE后没有立即执行依赖日期格式的查询，中间连接被释放回池，再次取出时设置已经丢失。
• 隐性的会话重置：有些数据库操作（比如某些系统存储过程、跨库查询）可能会隐性重置会话的语言设置，导致你的SET LANGUAGE被覆盖。

二、改默认语言触发登录错误的原因 #

你看到的Error 18456 State 28和Error 18056 State 28，核心问题是连接池复用了旧连接：

• 你修改登录默认语言时，用了Pooling=False的连接，但后续业务连接的连接字符串没关闭池，池里的旧连接仍然持有原来的语言配置。当SQL Server尝试重新验证这些旧连接时，无法匹配新的默认语言设置，就会触发登录验证失败，导致连接重置报错。

三、可行的解决方案 #

根据你的测试场景，推荐几个“短平快”的可靠方案：

1. 会话级强制设置语言（优先推荐） #

既然SET LANGUAGE是会话级的，那就在每次获取连接后立即执行这个设置，确保业务查询所在的会话都生效。比如封装你的连接获取逻辑：

private SqlConnection GetConfiguredConnection(string connectionString)
{
    var conn = new SqlConnection(connectionString);
    conn.Open();
    // 打开连接后立即设置语言
    using (var cmd = conn.CreateCommand())
    {
        cmd.CommandText = "SET LANGUAGE Deutsch;";
        cmd.ExecuteNonQuery();
    }
    return conn;
}

如果用了Entity Framework这类ORM，可以在DbContext初始化时执行这个语句，比如在构造函数里添加：

public MyDbContext() : base("YourConnectionString")
{
    Database.ExecuteSqlCommand("SET LANGUAGE Deutsch;");
}

2. 修改默认语言后强制清空连接池 #

如果一定要通过修改用户默认语言来解决，那改完后必须清空连接池，避免旧连接复用：

public void ChangeLanguage()
{
    ExecuteSql(@"USE [master]; ALTER LOGIN [myuser] WITH DEFAULT_LANGUAGE=[Deutsch]");
    // 清空所有连接池，确保后续连接都用新的语言设置
    SqlConnection.ClearAllPools();
}

测试期间可以把业务连接字符串也加上Pooling=False，彻底避免连接复用问题，测试结束后再改回来。

3. 直接设置日期格式（更精准） #

既然核心问题是日期格式，没必要切换整个语言，直接设置会话的日期格式更稳妥：

SET DATEFORMAT dmy; -- 德语环境常用的日-月-年格式

同样，在每次打开连接后执行这个语句，效果和切换语言一致，但不会引入语言切换带来的其他隐性副作用。

总结 #

优先推荐方案1或方案3，因为会话级的设置更可控，不会影响登录级别的配置，也不容易触发连接池相关的报错。如果必须用默认语言的方式，记得一定要清空连接池。

备注：内容来源于stack exchange，提问作者Allu