简单的 SQL 命令不适用于特定参数

Posted 2023-05-07

【中文标题】简单的 SQL 命令不适用于特定参数

【英文标题】：Simple SQL command wont work on specific parameters

【发布时间】：2016-05-17 13:54:43

【问题描述】：

我有一个简单的 SQL 命令，它在某些给定参数中不起作用。 例如，如果 TweetID = 59 和 UserID = 1 它将返回值； 但如果TweetID = 8 和UserID = 1 不会返回值。 有人能找到原因吗？

public static int GetReTweetIdFromReTweetByUserIdAndTweetId(int TweetID,int UserID)

    string sql = "SELECT [ReTweetID] FROM [ReTweet] WHERE [TweetID] = [@TID] AND [UserID] = [@UID]";
    OleDbConnection conn = ConnectToDb();
    OleDbCommand com = new OleDbCommand(sql, conn);
    com.Parameters.Clear();
    OleDbParameter objParamater;
    objParamater = com.Parameters.Add("[@UID]", OleDbType.Integer);
    objParamater.Direction = ParameterDirection.Input;
    objParamater.Value = UserID;
    objParamater = com.Parameters.Add("[@TID]", OleDbType.Integer);
    objParamater.Direction = ParameterDirection.Input;
    objParamater.Value = TweetID;
    OleDbDataAdapter da = new OleDbDataAdapter(com);
    DataTable dt = new DataTable();
    int id=0;
    try
    
        conn.Open();
        da.Fill(dt);
        id = int.Parse(dt.Rows[0][0].ToString());
    
    catch (Exception err)
    
        throw err;
    
    finally
    
        da.Dispose();
        dt.Dispose();
        com.Dispose();
        conn.Close();
        conn.Dispose();
    
    return id;

【问题讨论】：

离题：查看using statement。它可以大量清理您的代码，并省去在 IDisposable 对象上调用 Dispose() 的麻烦。

不要在你的 catch 块中throw err，因为这会重置堆栈跟踪。要么只是做一个throw，要么完全摆脱 catch 块，因为你在浪费你的时间。

如果直接对数据库运行脚本，它会返回结果吗？

@Rokni ***.com/a/881489/1666620

@Rokni 你看过我发布的链接了吗？对于实现IDisposable 接口的类的实例，您可以用一行using 语句替换try...catch...finally 块。 using 语句只是 try...catch...finally 块的简写，它在 finally 块中为 using 语句中指定的实例调用 Dispose()。这是链接：dotnetperls.com/using

【参考方案1】：

将 OleDb 与 Access 数据库一起使用时，将忽略参数名称。您必须按照 Access 预期的顺序提供参数值。如果您从 Access 查询设计器运行此查询...

SELECT [ReTweetID] FROM [ReTweet] WHERE [TweetID] = [@TID] AND [UserID] = [@UID]

...您将看到 Access 要求您先提供 [@TID] 的值，然后再提供 [@UID] 的值。

但在您的 c# 代码中，您以相反的顺序提供参数值。

但是，可能还有其他一些东西会混淆这个问题，因为我不明白为什么它在 TweetID = 59 和 UserID = 1 的情况下成功。只有当表实际上包含 TweetID = 1 的行并且这对我来说才有意义UserID = 59。也许确实如此。但无论哪种方式，我都敦促您首先按照 Access 期望的顺序提供参数值，然后查看是否需要进行额外的代码更改。

【讨论】：

谢谢它工作不知道访问是这样工作的，我也不知道为什么它与第一个参数一起工作。

实际上 Access 并不总是这样工作。例如，当从 DAO 执行查询时，参数名称是有意义的。我认为只有在从 OleDb 或 ADO（基于 OleDb）执行 Access 查询时才会忽略参数名称。

我确实使用了 Oledb 和 ADO，但它使用了一组不同的参数，这很奇怪。

嗯。我很惊讶。我可能需要修改我对此的想法，但我将把它留到另一天。 :-)