有没有办法确定 SQL Server 存储过程返回记录集

发布于 2024-10-16 01:49:39 字数 456 浏览 6 评论 0原文

我们有一个内部应用程序,它生成 ASP 代码来调用 Oracle 和 SQL 存储过程。

该应用程序查询相应的数据字典,并且能够确定参数信息,并相应地构造调用。使用此应用程序的开发人员可以将代码包含在他们的项目中,并使用专用的 DTO(也由应用程序生成)将数据传递给它。

在 Oracle 中,我们可以愉快地确定是否返回记录集,因为我们使用引用游标,并且这些显示在 Oracle DDL 的参数列表中。

SQL Server 的情况并非如此。目前开发人员自己必须知道SQL Server SP是否返回记录集,并在界面上勾选一个选项。这又决定了生成的代码是否包含 ExecuteQueryExecuteNonQuery

虽然这没问题,但如果没有这个选项就好了。有没有一种方法可以通过检查数据字典或其他方式以编程方式确定他的值?

谢谢,

詹姆斯

We have an internal application which generates ASP code to call Oracle and SQL Stored procedures.

This application queries the respective data dictionaries, and is able to determine parameter information, and construct the call accordingly. A developer using this application can include the code in their project, and pass data to it using a dedicated DTO (also generated by the app).

In Oracle, we can happily determine if a recordset is returned, as we use refcursors, and these show up in the parameter list on the Oracle DDL.

This not the case for for SQL Server. Currently the developers themselves have to know whether the SQL Server SP returns a recordset, and tick an option on the interface. This, in turn, determines whether the code generates contains ExecuteQuery or ExecuteNonQuery.

While this is ok, it would be nice no to have that option. Is there a way that his can be determined programatically by inspecting the data dictionary or by some other means?

Thanks,

James

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

单挑你×的.吻 2024-10-23 01:49:39

您可以使用 SET FMTONLY [ON 来检查 SQL 语句生成的结果集格式|关闭]
Reporting Services 等 MS 工具使用此技术来确定输出结果集的结构。

这对于存储过程来说很棘手,因为输出结果集的数量和结构可能会根据输入参数值而变化。如果您的过程代码不简单,那么即使有严格的编码标准,这也很难解决。

我见过其他方法(例如使用扩展参数),但没有一个是绝对可靠的。让开发人员勾选一个框可能是最好的解决方案。

You can inspect the resultset format produced by a SQL statement using SET FMTONLY [ON|OFF].
MS tools such as Reporting Services use this technique to determine the structure of output resultset(s).

This is tricky for stored procedures because the number and structure of the output result sets could vary depending on the input parameter values. This is difficult to get around - even with strict coding standards - if your procedure code is non-trivial.

I've seen other approaches (such as using extended parameters), but none are infallible. Having the developers tick a box may be the best solution.

我恋#小黄人 2024-10-23 01:49:39

不,因为您可以编写一个有时仅根据您选择的逻辑或参数返回结果集的过程。它很可能很难维护,但没有什么可以阻止你这样做。

因此,在一般情况下,您永远无法知道过程的此执行是否会返回结果集,这意味着系统没有可以有效存储的元数据。

No, because you can write a procedure that only returns result sets sometimes, based on whatever logic or parameters you choose. It would most likely be hard to maintain, but there is nothing preventing you from doing it.

Therefore, in the general case you can never know if this execution of a procedure will return a result set or not, and that means there's no metadata the system could usefully store about it.

苍暮颜 2024-10-23 01:49:39

尝试以下变化:-
选择 o.name、p.name、t.name、p.max_length、p.is_output
来自 sys.parameters p
内连接 sys.objects o on o.object_id = p.object_id
内连接 sys.types t on t.user_type_id = p.user_type_id
按姓名订购;

(您可以将其创建为视图)。

Try a variation on :-
select o.name, p.name, t.name, p.max_length, p.is_output
from sys.parameters p
inner join sys.objects o on o.object_id = p.object_id
inner join sys.types t on t.user_type_id = p.user_type_id
order by o.name;

(You could create this as a view).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文