同时用Entity Framework与Native SQL连SQL Server时WinDev报错117，求排查

首先，咱们先拆解这个错误：SQL Server错误码117对应的是指定的结果集中不存在目标列（法语原文是La colonne %d est introuvable dans le jeu de résultats spécifié）。你遇到的.NET端正常、WinDev报错的情况，基本和「访问优先级」无关，核心是两者对SQL查询的处理逻辑、连接配置或者结果集解析规则不一样导致的，下面具体说几个最可能的原因：

1. 执行的SQL语句存在差异 #

EF是ORM框架，会根据你的实体映射自动生成查询语句，而WinDev用的是你手动编写的原生SQL。很可能你的WinDev SQL里引用了不存在的列——比如列名拼写错误、别名写错，或者表结构更新后没同步WinDev的查询语句。
举个例子：如果EF自动生成的是SELECT Id, UserName FROM dbo.Users，但WinDev里写的是SELECT Id, FullName FROM dbo.Users，而实际表中根本没有FullName列，自然会触发错误117。

2. 结果集解析的严格性不同 #

WinDev的原生SQL驱动对结果集的解析逻辑比EF更“死板”：

• 如果你在WinDev代码里硬编码了列的索引位置（比如用Colonne(2)来获取第二列），但实际查询返回的列顺序或数量发生了变化，就会报错找不到对应索引的列；
• 而EF是基于实体类的属性映射来解析结果，只要列名和属性名匹配，不管列的顺序如何，都能正常解析，所以不会触发这个错误。

3. 连接配置的细节差异 #

虽然都是连接同一个SQL Server，但WinDev和.NET的连接字符串可能藏着细节差异：

• 比如连接的数据库实例不同、默认Schema不一致（EF用dbo，WinDev用了其他自定义Schema），导致两边查询的其实不是同一个表；
• 或者WinDev开启了旧版TDS协议、特定的连接选项，使得对查询结果的处理和.NET的SQL驱动逻辑不一致。

4. 表结构缓存未同步 #

WinDev可能缓存了旧的数据库表结构元数据，而EF要么是实时读取数据库元数据，要么你已经更新过EF的实体模型。比如你最近修改了表的列（删除、重命名），WinDev的缓存没刷新，还是按照旧的列结构去解析结果集，自然会找不到对应的列。

建议的排查步骤 #

• 把WinDev里执行的原生SQL复制到SSMS里直接运行，检查是否能正常返回结果，确认列名、表名、Schema都正确；
• 对比WinDev和.NET的连接字符串，确保连接的是同一个数据库实例、同一个数据库，默认Schema一致；
• 把WinDev代码中硬编码列索引的地方改成按列名获取（比如用Colonne("Id")代替Colonne(1)）；
• 刷新WinDev的数据库元数据缓存（一般在WinDev的数据库工具面板里有刷新选项），让它读取最新的表结构。

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