SSIS 和首选数据提供程序（ADO.NET、ODBC）
现在 Microsoft 已正式将 OLE 声明为 passe. 我很好奇每个人都喜欢使用哪个提供商。我更喜欢 ADO.NET，但这只是因为我在向存储过程传递参数时可以使用变量名。我应该开始使用 ODBC 吗？
谢谢
Now that Microsoft has officially declared OLE as passe. I'm curious as to what provider everyone likes to use. I have a preference for ADO.NET but that's only because I can use variable names when I'm passing parameters to stored procs. Should I start using ODBC instead?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，您需要 .NET 中的 ADO.NET。如果数据库有 ADO.NET 提供程序，请使用它。 ODBC 用于从非托管代码访问本机数据。
No, you want ADO.NET in .NET. If the database has an ADO.NET provider use that. ODBC is for native data access from unmanaged code.
我意识到这是一个非常古老的问题，但我觉得已接受的答案还有很多有待改进的信息。
SSIS 的许多组件要么不支持 ADO.NET 连接，要么它们的 ADO.NET 对应组件缺少 OLE DB 版本的许多功能。出于这个原因，我实际上建议仍然使用 OLE DB 和 SSIS。
ADO.NET 在很多方面都更好，但是一旦您使用 ADO.NET 设置了整个解决方案，并且发现无法使用某些您期望可以工作的组件或功能，您就会发现自己陷入了痛苦的境地。
例如，您不能：
我确信还有更多的事情是您无法通过 ADO.NET 连接在 SSIS 中完成的，但我还没有遇到过它们。但恕我直言，在 SSIS 中使用 ADO.NET 的缺点已经足够多，除非它在工具中获得更多支持。
I realize this is a very old question but I feel that the accepted answer leaves a lot of information to be desired.
A lot of the components of SSIS either do not support ADO.NET connections or their ADO.NET counterpart is missing a lot of the functionality of the OLE DB version. I would actually recommend still using OLE DB with SSIS for this reason.
ADO.NET is better in a lot of ways but you'll find yourself in a world of hurt once you've got your whole solution setup with ADO.NET and find you cannot use some component or feature that you expected would work.
For example you cannot:
I'm sure there are more things that you cannot do in SSIS with an ADO.NET connection but I haven't run across them yet. But IMHO there are already enough drawbacks to outweigh the benefits of using ADO.NET in SSIS until it gets more support in the tooling.