SQLWorkbench与Tableau Prep执行同一段SQL是否应返回一致结果？

• 同一段SQL在SQLWorkbench环境中可完整执行，返回结果符合预期
• 将同一段SQL作为Complex SQL节点嵌入Tableau Prep流程后，持续抛出固定报错：

System error: AqlProcessor evaluation failed: [Amazon][Support] (40550) Invalid character value for cast specification.

• 初步定位报错指向数据类型处理逻辑差异，核心疑问为两个执行环境的运行结果不一致，是否来自SQL解释器的差异。

• 两个环境的SQL执行链路完全不同，解释器差异确实存在：SQLWorkbench属于直连数据库的客户端工具，会将编写的SQL原封不动下发到连接的数据库端，完全使用数据库原生的SQL解释器、隐式类型转换规则执行；Tableau Prep的复杂SQL节点不会将SQL全量透传给下游数据库，会先经过内置的AQL处理器做语法校验、字段类型预推导，再生成最终下发到数据库的执行语句，这层预解析逻辑的类型判定规则和数据库原生规则并不对齐。
• 该报错属于Tableau Prep长期未修复的已知问题：大量同场景用户反馈过同类报错，触发逻辑集中在SQL存在隐式类型转换的场景——比如字符串类型字段和数值、日期类型字段直接做比较/关联/聚合计算、未明确声明空值字段类型时，Prep的AQL处理器会先抽样扫描全量数据行推导字段类型，只要扫描到任意一行存在不符合推导类型的异常值（比如数值字段里混入了文本字符、日期字符串存在非法格式），就会直接抛出类型转换失败错误，不会像数据库原生执行器那样做容错兼容，也不会跳过异常行继续执行。

• 对SQL中所有涉及计算、关联、筛选的字段强制加显式类型转换，完全移除隐式转换逻辑：统一使用CAST(字段名 AS 目标数据类型)语法明确指定每个字段的输出类型，避免Prep的预解析逻辑做自动类型推导。
• 若使用的Tableau Prep版本支持字段类型自定义配置，关闭复杂SQL节点的自动推导字段类型开关，手动逐一匹配输出字段的正确类型。
• 上述方案无效时，可绕开Prep的SQL预解析环节：先在连接的数据库侧基于原SQL创建对应视图，再在Prep中直接连接该视图读取数据即可。

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