Access 2019配SQL Server 2017：ApplyFilter不支持子查询及性能问题咨询

ApplyFilter宏不支持子查询是已知产品限制 #

• 这是Access 2010及后续版本的宏解析器原生限制，和语法写法、通配符、引号格式调整没有任何关系。Access 2003时代的宏执行逻辑是直接将Where Condition参数的内容透传到数据库引擎，不做前置校验；2010版本之后，所有宏操作的参数新增了独立的客户端预校验环节，ApplyFilter的参数解析器仅支持基于当前记录源字段的简单比较表达式，不识别子查询、嵌套域函数这类非纯字段判断的语法结构，只要参数中出现子查询写法，就会直接触发“参数值无效”的报错。
• 该限制没有可通过系统配置开启的开关，你目前使用VBA直接设置窗体的Filter、FilterOn属性的方式是官方推荐的标准替代方案——VBA调用的是窗体原生过滤接口，不需要经过宏解析器的前置校验，任何复杂的合法SQL语法都可以正常传入执行。
• 额外提示：尝试调整通配符、引号格式对解决这个报错没有帮助，问题根因是宏解析器根本不识别子查询结构，不是语法合规性错误。

可编辑场景下的筛选下推实现方案 #

针对你观测到的Access拉取全表本地计算、传递查询只读的问题，可直接落地实现下推、且满足可编辑需求的方案有两种，不需要依赖繁琐的子窗体事件传值逻辑：

• 根因说明：Access连接SQL Server后端时，只有完全符合ANSI SQL标准、不包含Access本地特有语法的查询，才会被连接引擎识别为可下推逻辑，直接把查询语句发给SQL Server执行；只要查询中包含in (子查询)嵌套结构、JET SQL独有的*通配符、本地表/查询引用，连接引擎就会自动把所有涉及的表全量拉取到本地，再用ACE引擎完成计算，这也是SSMS1秒出结果、Access跑1分钟的核心原因。
• 方案1：将子查询改写为多表内连接结构，使用纯ANSI SQL写法
  把原来的JobPropertyID in (select ...)逻辑替换为和Properties表的内连接，同时将通配符从Access专用的*调整为SQL Server兼容的%，保证整个查询没有任何Access本地语法。改写示例：

  SELECT j.JobID, j.JobDescription, c.CompanyName 
  FROM (JobDetails j 
  LEFT JOIN Company c ON j.JobCompanyID = c.CompanyID)
  INNER JOIN Properties p ON j.JobPropertyID = p.PropertyID
  WHERE p.PropertyAddress LIKE '%High Street%'
  

  只要查询输出包含所有链接表的主键字段，这种基于原生链接表编写的查询生成的记录集是完全可更新的，Access连接引擎识别到这类标准SQL结构时，会自动把整个查询逻辑下推到SQL Server执行，性能和SSMS查询一致，完全适配可编辑窗体的需求。
• 方案2：用SQL Server端视图作为窗体记录源，通过Filter属性触发下推
  在SQL Server端提前将多表连接逻辑创建为视图，保证视图定义中返回所有表的主键字段，将窗体记录源直接绑定该链接视图。当用户修改搜索条件时，通过VBA给窗体的Filter属性赋值地址匹配的表达式，此时Access连接引擎会把Filter条件和基础查询拼接为完整的SQL下发到SQL Server执行，不会拉取全表数据。因为记录集包含完整主键信息，窗体的编辑功能不会受影响。
• 避坑提示：不要继续尝试在原生链接查询中保留in (子查询)的嵌套写法，Access连接引擎永远不会识别这类结构为可下推逻辑，只要出现这类语法，就一定会触发全表拉取的本地计算流程。

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