有没有人尝试过这些。这支持吗？

我正在尝试从 Visual Studio 2008 运行 SQL 存储过程，该过程将表值 UDT 参数作为输入。我在 Visual Studio 2008 中添加了这个参数，但是当我运行这个程序时，它得到一个“ArgumentException - 指定类型未在目标服务器上注册”。所以我用谷歌搜索了这个问题，并认为我需要在 Visual Studio 2008 中创建一个新类，以匹配 SQL Server 2008 中此表类型的属性。但我在 Internet 上找不到任何涉及表UDT 的示例。我尝试了所有标量 UDT 示例，但我不确定如何修改它们以使其基于表。
我还阅读了我可能需要创建一个程序集，尽管我不知道这是否仅用于将类型导入 SQL Server 2008 或者它是否也可用于将类型导入 Visual Studio。顺便说一句，我没有看到 VS 2008 中的服务器资源管理器列出的任何类型，尽管我确实看到了数据库及其 SP。我尝试刷新数据库，但类型仍然没有显示。我需要做的很简单。我有一个像这样的表UDT：

我的 C# 代码中的代码片段是：

RowsAffected 显示运行此命令后受影响的零行。我错过了什么？你能把我指向一个展示这个简单例子的网站吗？还是给我小费？我也试过'param.UdtTypeName="parseInputFile";' 对于上面的代码段，但这返回了相同的错误。顺便说一句，“myStringArray”本质上是一个表。它是一系列字符串。例如 myStringArray[0] = "Hello|Bob|How|Do", myStringArray[1] = "I|Am|Fine|And" 等等。

这个来自 SQL Server 2008 BOL的页面讨论了 CLR 存储过程，并有一个标记为“表值参数”的部分，其中讨论了它们如何具有优势。太好了 - 我很想在我的 CLR procs 中使用 TVP，但不幸的是，这似乎是宇宙中唯一提到这种可能性的参考，并且该部分没有描述语法是什么（也没有进一步的信息链接在段落末尾）

当然，我可以很容易地找到关于如何从 T-SQL 过程中使用 TVP 的描述，或者一般来说如何执行 CLR 过程。但是编写一个需要 TVP 的 CLR proc？没有。这都是非常不常用的，因为将多行数据传递到存储过程是一个流行的问题。

这让我想知道该页面上的部分是否存在错误。有人请告诉我不是，并指出更多信息/示例。

[编辑]

当我遇到这个时，我也正准备将这个发布到一个 MS 论坛，这似乎是棺材上的最后一颗钉子。看来是做不到了。

我有一个字典定义为的代码：

Dictionary 中的每个 KeyValuePair 中的每个 Value 实际上是当前创建的三个单独的值，如下所示：

如您所见，三个值由“|”分隔。字典中的“行”数可以在 600-1200 之间。我想使用一个表值参数在一次操作中在我的 SQL Server 2008 DB 中获取所有这些。

表值参数定义如下：

从字典中获取可以传递给表值参数的东西的最佳方法是什么？我应该使用字典以外的东西吗？或者，我是否需要将 Dictionary 解析为另一个更好的数据结构？

谢谢。

我一直在研究 SQL Server 2008 中的表值参数，我发现当将这样的参数传递给存储过程时，会向数据库服务器发送如下查询：

我的问题是，鉴于插入语句没有参数化，这对 SQL 注入攻击有多安全？我尝试了最微不足道的攻击，并且引号被正确地转义了，但是有没有人进行了详尽的测试，或者这里还有其他事情可以保护我吗？

右键单击 TVP 时，我没有得到像“ALTER TO”这样的选项

我将不得不使用 SQL Server 的BULK INSERT命令重写一些相当旧的代码，因为架构已经改变，我想到也许我应该考虑改用 TVP 切换到存储过程，但我想知道什么效果它可能对性能有影响。

一些背景信息可能有助于解释我为什么要问这个问题：

• 数据实际上是通过 Web 服务传入的。Web 服务将一个文本文件写入数据库服务器上的共享文件夹，该文件夹依次执行BULK INSERT. 这个过程最初是在 SQL Server 2000 上实现的，当时除了在服务器上扔几百条语句之外真的别无选择INSERT，这实际上是原始过程，并且是性能灾难。

• 数据被批量插入到永久暂存表中，然后合并到一个更大的表中（之后从暂存表中删除）。

• 要插入的数据量是“大”的，但不是“巨大的”——通常是几百行，在极少数情况下可能会超过 5-10k 行。因此，我的直觉是，BULK INSERT作为一个非日志操作不会有那么大的区别（但我当然不确定，因此是这个问题）。

• 插入实际上是一个更大的流水线批处理过程的一部分，需要连续发生多次；因此性能至关重要。

我想BULK INSERT用 TVP 替换的原因是：

• 在 NetBIOS 上编写文本文件可能已经花费了一些时间，而且从体系结构的角度来看是相当可怕的。

• 我相信临时表可以（并且应该）被淘汰。它存在的主要原因是插入的数据需要在插入的同时用于其他几个更新，并且尝试从大量生产表中进行更新比使用几乎为空的 staging 成本要高得多桌子。使用 TVP，参数基本上是临时表，我可以在主插入之前/之后用它做任何我想做的事情。

• 我几乎可以消除重复检查、清理代码以及与批量插入相关的所有开销。

• 如果服务器一次获得一些此类事务，则无需担心临时表或 tempdb 上的锁争用（我们试图避免它，但它确实发生了）。

我显然会在将任何东西投入生产之前对此进行分析，但我认为在我花费所有时间之前先询问一下可能是个好主意，看看是否有人有任何关于为此目的使用 TVP 的严厉警告。

所以 - 对于任何对 SQL Server 2008 足够熟悉并尝试过或至少对此进行过调查的人来说，结论是什么？比如说，几百到几千行的插入，在相当频繁的基础上发生，TVP 会减少芥末吗？与批量插入相比，性能是否存在显着差异？

更新：现在问号减少了 92%！

（又名：测试结果）

经过 36 个阶段的部署过程后，最终结果现已投入生产。两种解决方案都经过了广泛的测试：

• 删除共享文件夹代码并SqlBulkCopy直接使用该类；
• 使用 TVP 切换到存储过程。

为了让读者可以了解究竟测试了什么，以消除对这些数据可靠性的怀疑，这里是这个导入过程实际作用的更详细的解释：

1. 从通常有 20-50 个数据点的时间数据序列开始（尽管有时可能多达几百个）；

2. 对它进行一大堆疯狂的处理，这些处理大多独立于数据库。这个过程是并行的，因此（1）中大约有 8-10 个序列同时被处理。每个并行进程生成 3 个附加序列。

3. 取所有 3 个序列和原始序列并将它们组合成一个批次。

4. 将所有 8-10 个现已完成的处理任务中的批次组合成一个大的超级批次。

5. 使用BULK INSERT策略（参见下一步）或 TVP 策略（跳至步骤 8）导入它。

6. 使用SqlBulkCopy该类将整个超级批次转储到 4 个永久暂存表中。

7. 运行一个存储过程，它 (a) 对 2 个表执行一系列聚合步骤，包括几个JOIN条件，然后 (b)MERGE使用聚合数据和非聚合数据对 6 个生产表执行 a。（完成的）

   或者

8. 生成4个DataTable包含待合并数据的对象；其中 3 个包含 CLR 类型，遗憾的是 ADO.NET TVP 没有正确支持这些类型，因此必须将它们作为字符串表示形式插入，这会稍微损害性能。

9. 将 TVP 馈送到存储过程，该过程与 (7) 进行基本相同的处理，但直接使用接收到的表。（完成的）

结果相当接近，但 TVP 方法最终平均表现更好，即使数据稍微超过 1000 行也是如此。

请注意，此导入过程连续运行数千次，因此只需计算完成所有合并所需的时间（是的，小时），就很容易获得平均时间。

最初，平均合并几乎需要 8 秒才能完成（在正常负载下）。删除 NetBIOS 杂物并切换到SqlBulkCopy将时间减少到几乎正好 7 秒。切换到 TVP 进一步将时间减少到每批5.2 秒。对于一个运行时间以小时为单位的进程来说，这提高了35%的吞吐量——所以一点也不差。它也比SqlBulkCopy.

我实际上相当有信心，真正的改进远不止于此。在测试过程中，很明显最终合并不再是关键路径。相反，执行所有数据处理的 Web 服务开始因请求的数量而崩溃。CPU 和数据库 I/O 都没有真正达到极限，也没有明显的锁定活动。在某些情况下，我们看到连续合并之间有几秒钟的空闲时间。使用时有一点差距，但要小得多（半秒左右）SqlBulkCopy。但我想这将成为另一天的故事。

结论：表值参数确实比BULK INSERT在中型数据集上运行的复杂导入+转换过程执行得更好。

我想补充一点，只是为了减轻部分支持登台的人的疑虑。在某种程度上，这整个服务是一个巨大的分期过程。该过程的每一步都经过严格审核，因此我们不需要临时表来确定某些特定合并失败的原因（尽管实际上它几乎从未发生过）。我们所要做的就是在服务中设置一个调试标志，它将中断调试器或将其数据转储到文件而不是数据库中。

换句话说，我们已经对流程有足够的了解，不需要临时表的安全性；我们首先拥有临时表的唯一原因是避免在所有我们必须使用的INSERT和语句上颠簸。UPDATE在最初的过程中，暂存数据在暂存表中只存在几分之一秒，因此在维护/可维护性方面没有增加任何价值。

另请注意，我们并没有用 TVP替换每个BULK INSERT操作。处理大量数据和/或不需要对数据做任何特殊处理（除了将其扔到数据库之外）的几个操作仍然使用SqlBulkCopy. 我并不是说 TVP 是一种性能灵丹妙药，只是说它们SqlBulkCopy在这个特定的实例中成功了，涉及初始阶段和最终合并之间的几次转换。

所以你有它。指向 TToni 寻找最相关的链接，但我也很欣赏其他回复。再次感谢！

我在 SQL Server 2008 中有一个名为“GetPrices”的存储过程，带有一个名为“StoreIDs”的表值参数。

这是我为此 TVP 创建的类型：

我想从我的实体框架中调用 SP。但是当我尝试将存储过程添加到 EDM 时，我收到以下错误：

函数“GetPrices”在参数索引 2 处有一个参数“StoreIDs”，该参数具有不受支持的数据类型“表类型”。该功能被排除在外。

有什么解决方法吗？有什么想法吗？

法比奥

有谁知道是否可以使用 Visual Studio / SQL Server Management Studio 调试器来检查传递给存储过程的表值参数的内容？

举一个简单的例子：

在 exec 语句上使用上面的断点，我可以毫无问题地进入存储过程。调试器显示 @controllerData local 的值为 '(table)' 但我没有找到任何工具可以让我实际查看构成该表的行。

我正在修改代码以使用 TVP 将数据从我们的 VB.NET 应用程序发送到 SQL 2008 DB，并尝试保持所有写入的原子性。

将此页面用作一般指南： http ://www.sqlteam.com/article/sql-server-2008-table-valued-parameters

我正在创建要发送到 SQL 存储过程的所有代码内数据表

但是，我将不得不为多个表重复创建这些数据表和数据列（然后将列添加到表中）。就我而言，这些数据表中的每一个都将具有与 SQL Server 表相同的布局（自动编号 PK 和 GUID 除外）......

有没有办法自动生成这个数据表创建代码？或者一般来说有更快的方法吗？

谢谢