web-dev-qa-db-fra.com

Tables temporaires dans les procédures stockées

Je me suis posé des questions sur les tables temporaires dans les sp et sur tout ce qui peut affecter la simultanéité… .. SP créé sur un serveur MSSQL 08.

Si j'ai un SP où je crée une table temporaire et la redépose comme ceci:

BEGIN

CREATE TABLE #MyTempTable
(
   someField int,
   someFieldMore nvarchar(50)
)

... Use of temp table here
... And then..

DROP TABLE #MyTempTable

END

Ce SP sera appelé très souvent, alors ma question est la suivante: peut-il y avoir des problèmes de simultanéité ici?

sql-serverstored-procedures
30
The real napster

Nan. Des instances indépendantes de la table temporaire seront créées pour chaque connexion.

31
Mehrdad Afshari

Peut être.

Les tables temporaires préfixées par un # (#exemple) sont conservées par session. Ainsi, si votre code appelle à nouveau la procédure stockée alors qu'un autre appel est en cours d'exécution (par exemple, des threads d'arrière-plan), l'appel de création échouera, car il existe déjà.

Si vous êtes vraiment inquiet, utilisez plutôt une variable de table

DECLARE @MyTempTable TABLE 
(
   someField int,
   someFieldMore nvarchar(50)
)

Ce sera spécifique à "l'instance" de cet appel de procédure stockée.

20
blowdart

Pas vraiment et je parle de SQL Server. La table temporaire (avec single #) existe et est visible dans la portée dans laquelle elle est créée (liée à la portée). Chaque fois que vous appelez votre procédure stockée, une nouvelle étendue est créée. Par conséquent, cette table temporaire n'existe que dans cette étendue. Je crois que les tables temporaires sont également visibles pour les procédures stockées et les fichiers UDF appelés dans cette étendue. Si vous utilisez cependant double livre (##), ils deviennent globaux dans votre session et sont donc visibles par les autres processus en cours dans le cadre de la session dans laquelle la table temporaire est créée. concurremment est souhaitable ou non.

7
Mehmet Aras

Pour tous ceux qui recommandent d'utiliser des variables de table, soyez prudent. La variable de table ne peut pas être indexée alors qu'une table temporaire peut l'être. Une variable de table est préférable lorsque vous travaillez avec de petites quantités de données, mais si vous travaillez sur de plus grands ensembles de données (par exemple, 50 000 enregistrements), une table temporaire sera beaucoup plus rapide qu'une variable de table.

N'oubliez pas non plus que vous ne pouvez pas compter sur try/catch pour forcer un nettoyage dans la procédure stockée. certains types d'échecs ne peuvent pas être capturés dans un try/catch (par exemple, des échecs de compilation en raison d'une résolution de nom retardée) si vous voulez vraiment être certain que vous devrez peut-être créer une procédure stockée wrapper pouvant effectuer un try/catch de la procédure stockée de l'agent et faire le nettoyage là-bas.

par exemple. créer proc worker AS COMMENCER - faire quelque chose ici FIN

create proc wrapper AS
BEGIN
    Create table #...
    BEGIN TRY
       exec worker
       exec worker2 -- using same temp table
       -- etc
    END TRY
    END CATCH
       -- handle transaction cleanup here
       drop table #...
    END CATCH 
END
2
Justin

Selon les livres SQL Server 2008, vous pouvez créer des tables temporaires locales et globales. Les tables temporaires locales ne sont visibles que dans la session en cours et les tables temporaires globales sont visibles pour toutes les sessions. 

'#table_temporal

'## table_global

Si une table temporaire locale est créée dans une procédure stockée ou une application pouvant être exécutée simultanément par plusieurs utilisateurs, le moteur de base de données doit pouvoir distinguer les tables créées par les différents utilisateurs. Pour ce faire, le moteur de base de données ajoute en interne un suffixe numérique à chaque nom de table temporaire local. 

Ensuite, il n'y a pas de problème.

0
fylex