SQL Server 2016+SharePoint2013 OData Source执行报错：找不到‘connexion’连接求助

这种情况我之前帮同事排查过好几次，大概率是OData Source背后藏了你没注意到的连接引用，或者包的元数据里残留了旧的配置信息——虽然你在UI里看不到这个叫connexion的连接，但执行时就会触发这个错误。给你几个靠谱的排查和解决步骤：

1. 检查OData Source的连接配置细节 #

• 打开你的OData Source编辑器，切换到Connection Manager标签页，确认当前选中的是你实际配置的那个连接，没有拼写错误或者隐藏的别名。
• 再点一次Test Connection验证，确保连接本身是正常可用的。

2. 清理SSIS包的XML元数据残留 #

有时候SSIS包的底层XML文件里会残留旧的连接引用，哪怕你在设计器里删了也还存在。可以这么操作：

• 关闭SSIS设计器，找到你的.dtsx包文件，用记事本或者VS Code打开它。
• 搜索关键词connexion，看看有没有相关的连接字符串、连接管理器引用节点。如果找到的话，小心删除对应的XML片段（注意别破坏其他正常的结构）。
• 保存文件后重新打开，再执行包试试。

3. 重新创建OData Source组件 #

如果上面的方法没用，可能是组件本身的配置出了问题：

• 删除当前的OData Source组件，从工具箱里重新拖一个新的到数据流中。
• 重新一步步配置连接和数据选择，确保和之前测试成功的配置完全一致，然后再执行包。

4. 检查项目/包级的连接管理器 #

• 如果用的是项目部署模型，打开Solution Explorer里的Connection Managers文件夹，检查所有项目级连接的名称，确保没有这个不存在的connexion。
• 包级的连接管理器也同样检查一遍，有没有拼写错误或者重名的情况。

5. 验证SharePoint OData服务的兼容性 #

虽然测试和预览成功，但执行时的上下文可能和测试时不一样：

• 确认你的SQL Server 2016 SSIS版本支持SharePoint 2013的OData服务（SQL Server 2016的SSIS对OData的支持是没问题的，但可以检查下是否有未安装的累积更新）。
• 用浏览器直接访问SharePoint列表的OData URL（比如http://你的SharePoint站点/_vti_bin/listdata.svc/你的列表名），确认能返回正常的XML数据。

补充一句：错误里的connexion是法语的“连接”，如果你的SSIS环境是法语本地化版本，可能底层生成了一些本地化的连接引用名，这时候清理包的XML元数据会更有效。

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