OleDB解析\n\r遇异常，如何通过OleDB向数据库传入多行字符串？

你遇到的问题根源是直接拼接SQL语句时的特殊字符解析错误，而且这种写法还存在SQL注入风险，我推荐用参数化查询来解决，这是处理这类场景最稳妥的方式，具体方案如下：

为什么之前的尝试失败？ #

你之前直接在SQL语句里拼接chr(13)||chr(10)或者\r\n的做法，会让OleDB把这些换行符当成SQL语句本身的一部分，而不是字符串内容的一部分，导致SQL语法解析失败，触发"未指定错误"。另外替换单引号为双引号的操作，不符合OleDB对字符串的常规语法要求，自然也会报错。

正确解决方案：使用参数化存储过程调用 #

参数化查询会自动处理字符串中的特殊字符（包括换行符），不需要手动转义，同时还能避免SQL注入。以下是C#的示例代码：

using (OleDbConnection conn = new OleDbConnection("你的数据库连接字符串"))
{
    conn.Open();
    
    // 声明调用存储过程的命令，指定命令类型为存储过程
    using (OleDbCommand cmd = new OleDbCommand("merge_procedure", conn))
    {
        cmd.CommandType = CommandType.StoredProcedure;
        
        // 添加第一个参数（对应存储过程的12345参数）
        cmd.Parameters.Add(new OleDbParameter("@Id", OleDbType.Integer)).Value = 12345;
        
        // 构造包含换行的多行字符串，直接传入参数
        string multiLineContent = "Datum poskytnutí" + Environment.NewLine + "dokumentace";
        cmd.Parameters.Add(new OleDbParameter("@Content", OleDbType.VarChar, -1)).Value = multiLineContent;
        
        // 执行命令
        cmd.ExecuteNonQuery();
    }
}

关键说明 #

1. 参数化自动处理特殊字符：OleDB会负责把参数中的\r\n（也就是Environment.NewLine）正确传递给数据库存储过程，不需要你手动拼接chr(13)或chr(10)。
2. 避免SQL注入：直接拼接SQL的方式存在注入风险，参数化查询能彻底规避这个问题。
3. 适配不同数据库：这种写法不依赖特定数据库的字符串转义规则，通用性更强。

如果因为某些原因必须用拼接SQL的方式（非常不推荐），你需要确保换行符被正确转义为数据库能识别的格式，比如在Oracle中可能需要用chr(13)||chr(10)，但必须确保整个字符串被正确包裹，同时处理好单引号的转义（比如把字符串中的单引号替换为两个单引号），但这种方式容易出错且不安全，还是参数化查询更可靠。

内容的提问来源于stack exchange，提问作者Lukáš Linhart