Denali 结果集的实时应用/优势
Denali 的结果集的实时用途是什么 到目前为止，除了在运行时重命名列名称和数据类型之外，Sql 存储过程还值得关注。
甚至在运行时更改结果集的数据类型有什么好处，
例如
Alter PROCEDURE test_Proc
AS
BEGIN
SELECT * FROM tbl_Test
END
GO
EXEC test_Proc
WITH RESULT SETS
(
( Id int,
EmpName varchar(50),
PNo varchar(50)
)
)
即使列数据类型已更改，我们将如何处理？
但是 这篇文章给出了一些关于它在 SSIS 中的好处的想法。但我更感兴趣的是 Sql Server 存储的 Proc 与任何前端应用程序（例如 c#）等进行交互。
What are the real time uses of the Denali's With Result Set so far Sql Stored Procs are concern apart from renaming the column names and data types at runtime.
Even what is the benefit of changing the datatypes at runtime in With Result Set
e.g.
Alter PROCEDURE test_Proc
AS
BEGIN
SELECT * FROM tbl_Test
END
GO
EXEC test_Proc
WITH RESULT SETS
(
( Id int,
EmpName varchar(50),
PNo varchar(50)
)
)
Even if the column datatypes has been changed, what will we do with that?
however this article gives some idea about it's benefit in SSIS. But I am more interested in Sql Server stored Proc talking to any front end application(e.g. c#) and the like prespective.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
举例来说，假设您的应用程序正在调用 sp_who2，并且它将 SPID 存储在 int32 中。 sp_who2 将 SPID 作为字符返回，要求您在所有应用程序中执行特殊处理以将输出转换为 int32。如果您创建包装过程，则可以在一个位置执行此操作，而不必先将结果转储到临时表中。 sp_who2 的一个更奇怪的情况是它返回两个相同的 SPID 列 - 使用WITH RESULT SETS，您可以重命名其中之一（例如，重命名为冗余_SPID），以便您的应用程序永远不会看到具有相同名称的多个列。
另一个用例是，您要将数据类型从 int64 更改为 int32 或将 int32 更改为 varchar，但您无法一次更改所有应用程序。您可以更改“现代”应用程序以使用新数据类型，同时让其他“现在不可更改”应用程序使用旧数据类型。这意味着您可以将应用程序的部署和测试一一分开，而不是在所有应用程序中进行批量数据类型更改。
Well, for one, say your application is calling sp_who2, and it is storing SPID in an int32. sp_who2 returns SPID as a char, requiring you to perform special handling in all of your apps to convert the output to an int32. If you create a wrapper procedure, you can do this in one place, and without having to dump the results into a temp table first. One more curious case with sp_who2 is that it returns two identical SPID columns - with WITH RESULT SETS you can rename one of them (say, to redundant_SPID) so that your apps never see multiple columns with the same name.
Another use case is say you are changing a data type from int64 to int32 or int32 to varchar, but you can't change all of your apps at once. You can change the "modern" apps to use the new data type while leaving the other "not changeable right now" apps to use the old data type. This means you can split out the deployment and testing of your apps one by one instead of making a wholesale data type change across all of the apps.