SQLite的WHERE子句比较失败返回预期的结果集

我目前工作的下面的代码：SQLite的WHERE子句比较失败返回预期的结果集

for (double i = 0.00; i < 5; i += 0.01) 
     { 
      cmd.CommandText = "SELECT " + 
      "COUNT(DISTINCT(ActualAFR)) " + 
      "FROM tblBaseLog AS tBL " + 
      "INNER JOIN tblSettings AS tSET " + 
      "ON tBL.RPM = tSET.RPM " + 
      "WHERE MAFVoltage = " + i + " AND " + 
      "(tBL.AccelPedalPos > tSET.APPTransition OR " + 
      "tBL.CalculatedLoad > tSET.LoadTransition)"; 

      int trimCount = Convert.ToInt32(cmd.ExecuteScalar().ToString());

我遇到的问题是特定于查询的最后一行的WHERE子句比较（特别是tBL.CalculatedLoad> tSET.LoadTransition）。

这个查询就像它现在的数据集返回一个结果;此结果是正确的，但不是预期的完整数据集。
如果我翻转操作数（从大于小于），我得到一个预期的但未经验证的结果（基本上是很多数据点）。
最奇怪的是，如果我以更高的值启动for循环（对于double i = 4.00; ...等），我会得到比以前更多的结果。

现在，我已经澄清所发生的事情，这里是属于结构上的相关信息/正在使用的数据库的内容：

表数据类型的一切都是设置为REAL，RPM只是一个简单的INTEGER。
tBL.AccelPedalPos> tSET.APPTransition的结果永远不会返回为真（不要问，现在没关系，是的，我已经将它从查询中移除了），所以它不是一个因素
为tSET.LoadTransition的值是几乎总是1除了在日志中早期它在哪里1.1
为tBL.Calculated负载的值0.2和2之间变化，以数百次的十进制值的迭代大于它应该比较的平坦1.0。

这可能是一些可笑的简单，我很想念，但是在重新编写查询几十次之后，我正在分手并寻求帮助。

也可能值得注意的是，我的电脑有一个“固定的”AMD TLB错误处理器;不过，我已经在运行Core 2 Duo的笔记本电脑上测试了应用程序的编译版本，并得到了相同的结果。

任何输入，将不胜感激。

来源

2012-04-26 Enki

浮点值的行为与整数值的行为不同;从0.00到5的循环将永远不会为我产生值4.0。

您可能希望为MAFVoltage指定一个范围（> last_value_of_i AND < = current_value_of_i）或使用decimal获得类似整数的准确度。

要验证我所说的问题是在您的案例中发生了什么，请首先记录CommandText属性i大于4--它应报告类似WHERE MAFVoltage = 4.0099999999999589的内容。

来源

2012-04-26 20:40:19

我已经看到了，但基于直接输入从i输入到表中的值产生预期的整数。有点奇怪。即使增量设置为+ = .01，它为什么会这样做？ – Enki 2012-04-26 20:42:57

这里有一篇像样的文章：http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm - 浮点值意味着接近一个值，非常适合测量，但不是适合完全匹配。小数点浮动在2的幂上，而不是我们在十进制系统中使用的10。 – 2012-04-26 21:02:38

看起来像Math.Round（i，2）.ToString（）将是我现在的答案，直到我可以做到这一点“正确的方式”，无论可能。谢谢！ – Enki 2012-04-26 21:06:21

SQLite的WHERE子句比较失败返回预期的结果集

回答

相关问题