临时表范围？

我正在使用临时表#tempTable在我的存储过程 - 这是我利用来运行我的ASP.net报告（报告服务）临时表范围？

我做这样的事情

如。代码

SELECT * INTO #tempTable FROM Contacts WHERE ContactID < 10

然后，我使用类似

SELECT o.* FROM #tempTable t INNER JOIN Orders o ON t.ContactID =o.ContactID

到值又名结果返回给我的报告，该存储过程

我不摆脱我#tempTable的

即我不这样做

DROP TABLE #tempTable

我已经读过，临时表的范围只适用于存储过程 - 所以正在做上述必要的 - 如果我不做以上问题，我将在未来遇到什么问题

来源

2010-07-26 soldieraman

@Tom：这可能是一个简单的例子。有时他们是必需的。 – Hogan 2010-07-26 23:27:58

它被认为是良好的编码习惯明确删除您创建的每个临时表。如果您通过SQL Server Management Studio/Query Analyzer执行脚本，临时表将一直保留，直到您明确放弃它们或直到您关闭会话。

来源

2010-07-26 02:52:39

但是，如果我通过ASP.net应用程序调用它们？ – soldieraman 2010-07-26 08:26:11

在存储过程中创建的本地临时表将在存储过程完成时自动删除。但是，我倾向于在我不再需要它们时立即放弃它们。我想这在复杂的长时间运行的存储过程中更重要。 – 2010-07-26 22:31:47

一般来说，你可能不会因为不放弃临时表而出现问题。本地临时表具有会话范围或SP范围。当会话关闭或SP完成时它会自动放下。

但是，您通过定期遵循此练习确实会增加出现问题的风险。例如，如果您不使用SP，但从ASP .net提交SELECT语句并保持打开SQL Server连接，临时表将继续存在。继续使用连接和其他临时表将导致tempdb随着时间的推移而增长。

我也支持在这种情况下使用临时表的其他意见。如果您创建没有临时表的解决方案，则可能会有更快的报告并避免使用DROP临时表命令。

来源

2010-07-26 22:29:57 bobs

首先，过程完成后，将删除在过程中创建的本地临时表。从BOL on Create Table：

在存储过程完成时，会自动删除在存储过程中创建的本地临时表。该表可以由创建该表的存储过程执行的任何嵌套存储过程引用。该表不能被调用创建该表的存储过程的进程引用。

如果您的数据访问代码正确地打开连接，调用存储过程然后关闭连接，则会在该过程中创建的临时表被有效销毁。

我说“有效”提出另一个观点。我不建议在过程结束时删除临时表，尽管在创建临时表之前我会添加一个检查并在存在的情况下删除它（例如if object_id('tempdb..#Foo') is not null）。反对在最后放弃临时表的观点是，通过调用Drop语句，您迫使SQL Server花费资源在您等待过程结束时耗费时间销毁表。相反，如果让它超出范围，则您的过程会立即结束，并让SQL Server在自己选择的时间销毁表。

来源

2010-07-26 23:19:34 Thomas

#Temp表的范围仅限于您的会话和批处理的生命周期，意味着其他人无法看到您的临时表，并且任何人都可以使用相同的名称创建自己的#Temp表。一旦你的会话或批处理结束，SQL Server将清理临时表。

在另一个注意事项## Temp表像行为像一个普通的表。每个人都可以看到它，并且不能超过1个##具有相同名称的临时表。 SQL Server将在服务器重新启动时清除这些## Temp表。

来源

2012-03-27 15:55:55 elvis

这并不完全准确。临时表不限于批次的范围 - 无论批次如何，它们都可以在整个会话中存活。也就是说，你可以创建一个临时表，使用'GO'，并且临时表将与其数据一起存在。 – ean5533 2013-01-03 18:23:43

我遇到了.NET SqlCommand中创建的临时表持续存在不会持续到第二个SqlCommand的情况，即使它们在同一个打开的连接上运行。 – Triynko 2015-02-25 21:03:07

临时表范围？

回答

相关问题