在我工作的地方，我们需要通过存储过程作为通过代码访问数据的机制。我正在使用LINQ2SQL来最大限度地减少这种痛苦，这样我就可以直接使用对象而不是ADO.NET。我有一种情况Linq2SQL正在使用我的存储过程中的一个生成代码，其中存储的proc调用的返回类型是int。存储过程实际上返回一个数据集。在做了一些研究之后，我发现这是因为SQLClient库无法正确分析sproc以生成Linq2SQL用来创建对象图的预期元数据。我的问题是如何构建sprocs（即使是复杂的），以便从linq2sql中获取对象图，或者换句话说，您应该避免在存储过程中出现什么问题，以免造成SQLClient库混淆，从而无法理解如何生成linq2sql为了创建对象图而消耗的元数据？优化存储过程，以便通过Linq2SQL正确处理它们
这是不实际的LINQ到SQL的限制，而是SQL Server的不能总是告诉客户什么样的返回类型将没有当它含有临时表，游标或动态SQL实际运行它的。
由于使用无效参数运行它可能是灾难性的，它不会尝试。
您可以使用设计手工设置，或者如果它是绝对好运行无效数据存储过程（即它是纯被动的），那么你可以关闭添加SET FMTOPT到存储的开始程序。
DamienG在微软的LinqToSql团队工作，我已经把他的答案视为正确。
这就是说，他可能不会从LinqToSql劝你离开，我想考虑这种选择是非常重要的。
试图猜测一个存储过程的返回类型是非常困难的，LinqToSql做它，以及任何人（用于SQL Server）。这就是说，有非常令人信服的理由不使用存储过程：
Stored procedures are bad, m'kay?
如果你必须保护你的表从开发商“安全原因”（我猜是你的情况），最好是用视图来代替存储过程。
如果您使用视图，那么在ORM部门中比在LinqToSql中有更多的选项。
你要在这方面遇到与LinqToSql的主要问题是什么工作正常，5个存储过程在一个很小的数据库中不为50个或500存储过程正常工作。您可以使用O/R设计器“覆盖”存储过程的返回类型，但当存储过程或表等操作时会遇到显着的同步问题。存储过程的更改不会反映在O/R Designer中，除非您从O/R设计器中删除存储过程，重新添加它，然后重新应用您的自定义覆盖。如果你的项目像任何普通的项目一样，表和存储过程经常变化，这个同步问题很快就会变成一场噩梦，因为它完全是手动的，如果你没有正确地做到这一点，你会在运行时得到非常奇怪的错误。
我强烈建议不要继续走下去。
我知道达米安是谁，我很看重他的评论。使用存储过程作为访问我们数据的机制的原因不是我个人可以控制的。这是一个架构决定，因此我们正在以.NET开发人员的身份消费。我问这个问题的目标是我们决定使用LINQ2SQL作为我们选择的O/R映射工具，并且我想向我们的DBA组提供我所能提供的任何信息，以便他们能够以这种方式编写存储过程因为我可以使用LINQ2SQL而不是必须使用ADO.NET。 – 2009-09-01 19:46:18
看过存储过程后，我们在存储区顶部的变量中进行了一些选择，以便设置它们，但我们也有一个Exec sprc命令，它也会返回存储区正文中的出参数。我猜想选入变量对Linq2Sql来说应该不是问题，但它可能是Exec命令，它可能会把它抛出。你知道这是否会导致Linq2Sql的问题？另一个值得关注的问题是Exec sproc有一个out参数，它被用在主sproc的主体中。 最好的问候， 迈克尔 – 2009-09-01 02:30:00
避免Exec sproc会是一个好的开始 - 它可以很容易地导致SQL注入并损害性能，就像动态SQL一样。 没有看到SP本身，很难猜测它是如何被重写的。 – DamienG 2009-10-01 23:32:02