问题标签 [ado.net]

使用 C# 和 System.Data.SqlClient，有没有办法在我实际执行之前检索属于 SQL Server 上的存储过程的参数列表？

我有一个“多环境”场景，其中有同一个数据库模式的多个版本。环境的示例可能是“开发”、“暂存”和“生产”。“开发”将有一个版本的存储过程，而“暂存”将有另一个版本。

我要做的就是在传递一个值并调用存储过程之前验证一个参数是否存在。避免 SqlException 而不必捕获它对我来说是一个加分项。

约书亚

这些天，当我有一个实现 IDisposable 的对象时，我越来越多地尝试利用 using 块，但我还没有弄清楚的一件事是如何像在正常的 try/catch/finally 中那样捕获异常......任何代码示例可以为我指明正确的方向？

编辑：阅读回复后修改了问题。它是“如何使用 .NET 2.0 在 using 块中引发异常？” 但我实际上是在寻找一种在 using 块中捕获这些异常的方法。

我正在寻找更多关于在 using 块内滚动我自己的捕获块的详细信息。

编辑：我想避免的是必须在我的 using 块中使用 try/catch/finally，就像 @Blair 显示的那样。但也许这不是问题......

编辑：@Blair，这正是我想要的，感谢您的详细回复！

我们的 Windows 窗体应用程序通过 ADO.NET 和 SOAP Web 服务从 SQL Server 的视图中提取记录，并在数据网格中显示它们。我们有几个大约 25,000 行的案例，工作相对顺利，但潜在客户需要在一个列表中包含很多倍。

为了弄清楚我们现在的扩展程度，以及我们可以实际改进的程度（和程度），我想实现一个模拟：让 SQL Server 发送虚构的随机数据，而不是显示实际数据。客户端和传输端基本相同；视图（或至少是基础表）当然会以不同的方式工作。用户指定虚构行的数量（例如 100,000）。

目前，我只想知道客户端需要多长时间来检索和处理数据并准备好显示它。

我想弄清楚的是：如何让 SQL Server 发送此类数据？

我是否：

1. 创建一个必须预先运行以填充实际表的存储过程？
2. 创建一个我指向的函数，从而让服务器“实时”生成数据？
3. 以某种方式复制和/或随机化现有数据？

第一个选项对我来说听起来会产生最接近现实世界的结果。因为数据实际上是“物理存在的”，所以SELECT查询在性能方面与对真实数据的查询非常相似。但是，它会通过其他无意义的操作对服务器征税。假数据也会被备份，因为它会存在于同一个数据库中——当然，除非我在每次运行基准测试后删除数据。

第二个和第三个选项在运行实际模拟时对服务器征税，因此可能会产生不切实际的缓慢结果。

此外，我不确定如何创建这些行，而不是使用循环或游标。SELECT top <n> random1(), random2(), […] FROM foo如果foo实际上碰巧有条目，我可以使用<n>，但否则我（显然）只会获得foo碰巧有的行数。AGROUP BY newid()或类似的东西似乎不起作用。

是否有人将 ADO.NET 数据服务用作 Adob​​e Flex 应用程序的数据源？如果是这样，有什么成功的故事或悲剧要避免吗？如果你确实使用了它，你是如何处理安全性的？

我对 ADO.Net 数据服务有点困惑。

它只是用于创建 RESTful Web 服务吗？我知道 WCF 始于 SOAP 世界，但现在我听说它对 REST 有很好的支持。ADO.Net 数据服务也是如此，如果您不能从面向资源的视图中查看所有内容，您可以使其在 RPC 模型中工作。

至少从我最近看到的演示来看，ADO.Net 数据服务似乎是在服务器上的 WCF 堆栈上构建的。如果我错了，请纠正我。

我不打算开始 REST 与 SOAP 辩论，但我想事情不再那么清晰了。

关于在哪里使用什么的任何建议或指南？

It seems like IDataReader.Read() is always true at least one time (If I'm wrong about this let me know.) So how do you tell if it has no records without just wrapping it in a try/catch?

我来自一个喜欢构建自己的世界而不是依赖他人构建的库和框架的世界。逃离这个世界后，我发现在 Visual Studio 中使用 Typed DataSets 等工具的乐趣和轻松。那么除了失去灵活性之外，你还失去了什么？是否有性能因素（忽略 procs 与动态 sql 的争论）？限制？

有没有人真正发布了一个实体框架项目，该项目将 O/R 映射到与数据存储中的表完全不同的概念类？

我的意思是将连接 (M:M) 表折叠到其他实体中，以形成存在于业务域中但在数据存储中组织为多个表的概念类。我在 MSDN 上看到的所有示例都很少使用继承、将联结表折叠成其他实体或将查找表折叠成实体。

我很想听听或查看以下示例，这些示例支持您通常希望在业务对象上执行的所有 CRUD 操作。：

1. 车辆表和颜色表。一种颜色可以出现在许多车辆中 (1:M)。它们形成了具有属性 Color 的概念类 UsedCar。

2. Doctor、DoctorPatients 和 Patients 表（形成多对多）。医生有很多患者，患者可以有很多医生（M:M）。绘制出两个概念类Doctor（具有Patients 集合）和Patients（具有Doctors 集合）。

有人在实体框架中使用 CSDL 和 SSDL 看到/做过这个吗？如果 CSDL 没有实际映射到任何东西，它就不好了！

我正在使用 ADO.NET 访问 SQL Server 2005，并且希望能够从我正在调用的 T-SQL 存储过程内部进行日志记录。这有可能吗？

使用 ADO.NET 时，我无法看到“打印”语句的输出，因为我只想使用日志记录来调试理想的解决方案是从 SysInternals 向 DebugView 发出消息。

我已经成功地编写了自己的 SQL 访问代码，并结合了存储过程和参数化查询以及我编写的一个小包装库，以最大限度地减少 ADO.NET 垃圾。过去，这一切对我来说都非常有效，而且我的工作效率很高。

我正在着手一个新项目——我应该把我的旧学校的东西抛在脑后，深入研究一个基于 ORM 的解决方案吗？（我知道 NHibernate 和 EF 之间存在巨大的高概念差异——我不想在这里讨论。为了争论，我们甚至将 LINQ 与老式替代方案混为一谈。）我正在寻找根据我所知道的（并且非常了解），就 ORM 类型的实际应用提出建议。

老式 ADO.NET 代码还是 ORM？我确定有一条曲线——这条曲线是否有让事情变得有价值的投资回报率？我很焦虑并愿意学习，但确实有截止日期。