这个问题我之前处理过，核心原因确实和Access的查询优化器执行逻辑有关，不是你的操作逻辑出错，而是Access没有严格按照你写的嵌套顺序执行查询。

为什么会报错？ #

你写的嵌套查询看似先过滤了Field1 IS NOT NULL的记录，但Access的查询优化器为了提升效率，会自动重写查询逻辑——它可能会把外层的Val(LEFT(Field1,4)) > 1002条件提前执行，这就导致null值被传入LEFT和Val函数，引发数据类型不匹配的错误（因为LEFT(null,4)返回null，Val(null)无法转换为数值类型）。

解决方法 #

这里有几个简单有效的解决方案，按推荐程度排序：

1. 直接合并WHERE条件（最推荐）

把非空判断和数值判断放在同一个WHERE子句里，Access的优化器会优先过滤null记录，再执行数值转换和比较：

SELECT * FROM Table1 
WHERE Field1 IS NOT NULL 
AND Val(LEFT(Field1, 4)) > 1002;

2. 用Nz函数处理潜在的null值

如果担心优化器还是乱序执行，可以用Nz函数把null转换为空字符串，确保LEFT函数始终有合法输入：

SELECT * FROM Table1 
WHERE Val(LEFT(Nz(Field1, ''), 4)) > 1002;

这种方式下，null会被转成空字符串，LEFT('',4)返回空，Val('')等于0，自然不会满足>1002的条件，相当于间接过滤了null记录。

3. 用CInt/CLng代替Val（适合固定格式的场景）

因为你的Field1格式是固定的（前四位是数字），也可以用CInt直接转换前四位为整数，但要注意如果前四位不是有效数字会报错，不过你的数据格式没问题的话，这个方法也可行：

SELECT * FROM Table1 
WHERE Field1 IS NOT NULL 
AND CInt(LEFT(Field1, 4)) > 1002;

总结 #

Access的查询优化器有时候会“自作主张”调整执行顺序，所以嵌套过滤null的方式不一定能生效。直接合并条件是最稳妥高效的做法，既符合你的需求，又能避免类型不匹配的问题。

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