C#中ADODB Connection与SqlConnection适用场景及VB6代码迁移问题

现有转换代码的修正点 #

你的核心转换逻辑（执行存储过程+遍历结果集）思路是正确的，但存在几个必须修改的细节问题：

1. SQL注入风险与存储过程调用不规范
   你目前通过字符串拼接EXEC语句的写法存在SQL注入风险，而且完全没必要手动拼接，.NET原生支持存储过程调用，写法更安全：

// 正确的存储过程调用写法
sSql = PROC_GETEPORTPARAMETERVALUES; // 直接填存储过程名即可
using (SqlConnection conn = new SqlConnection(ConfigurationManager.AppSettings["ConnectionString"]))
{
    if (conn.State != ConnectionState.Open)
    {
        conn.Open();
    }
    // 注意SqlCommand要关联连接对象，你之前的代码漏了这个参数会报错
    using (SqlCommand cmd = new SqlCommand(sSql, conn))
    {
        cmd.CommandType = CommandType.StoredProcedure;
        // 按顺序添加存储过程需要的参数，避免拼接风险
        cmd.Parameters.AddWithValue("@iTemplateId", iTemplateId);
        cmd.Parameters.AddWithValue("@iViewId", iViewId);
        cmd.Parameters.AddWithValue("@g_sTenantSN", GlobalHelper.Tenant);
        using (SqlDataReader dr = cmd.ExecuteReader())
        {
            while (dr.Read())
            {
                // 原有业务逻辑
            }
        }
    }
}

2. 非托管资源未释放
   SqlConnection、SqlCommand、SqlDataReader都属于需要手动释放的非托管资源，用using语句包裹可以在代码执行完成后自动释放资源，避免数据库连接泄露。
3. Command未关联连接
   你原来的代码中new SqlCommand(sSql)没有传入连接对象，执行时会直接抛出异常，必须把连接对象作为第二个参数传入构造函数。

ADODB与SqlConnection的选型规则 #

适合选择ADODB的场景 #

只有两种场景可以考虑使用ADODB：

• 迁移遗留项目时，原有代码重度依赖ADODB的Recordset游标、分页等特性，完全重写成本过高，可临时用ADODB做兼容过渡
• 需要对接无对应.NET托管驱动的极老数据源，只能通过ADODB的ODBC/OLEDB桥接访问
  其他场景不推荐使用ADODB：ADODB是COM组件，在.NET环境运行需要额外的互操作封装，性能更低，资源释放规则和.NET生态不兼容，也不支持异步、依赖注入等.NET新特性。

适合选择SqlConnection的场景 #

只要你对接的是微软SQL Server数据库，所有新写的.NET代码都优先选择SqlConnection（最新.NET版本推荐用Microsoft.Data.SqlClient包下的更新版本）：它是.NET原生托管驱动，性能远高于ADODB，完美适配.NET生态的各类ORM、异步API、配置系统，编码规范也更符合.NET开发标准。

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