Deux sessions peuvent-elles créer des tables #temp avec le même nom?

Je crée une table temporaire ( #myTable) et j'utilise un curseur. Cela crée-t-il un problème lorsque des utilisateurs simultanés accèdent au curseur via mon application? Est-ce que cela me permet de créer des tables temporaires distinctes avec le même nom?

Voici l'exemple de code:

Open cursor;
Fetch Next from cursor into @Variable_Temp_Table_Name;
Create table #myTable(pk int)
While @@Fetch_Status = 0
Begin    
Fetch Next from cursor into @Variable_Temp_Table_Name;
End

sql-server cursors

— sujith karivelil
source

Réponses:

Le serveur SQL ajoute toujours un nombre aléatoire à la fin d'un nom de table temporaire (en arrière-plan), lorsque les utilisateurs simultanés créent des tables temporaires dans leurs sessions avec le même nom, le serveur sql créera plusieurs tables temporaires dans la tempdb.

J'ai créé 3 tables temporaires appelées #TempTabledans trois sessions différentes dans mon SSMS, maintenant si je vais dans tempdb, je peux voir les tables temporaires créées là-bas avec une chaîne aléatoire (unique) ajoutée au nom de chaque table temporaire.

— M.Ali
source

Oui, plusieurs applications obtiendront leurs propres copies de la table #temp. C'est le point d'utiliser une table #temp, car chaque session simultanée a son propre objet isolé. Cela n'a rien à voir avec si vous utilisez un curseur en combinaison avec votre table #temp (bien que je soupçonne que le curseur n'est pas nécessaire de toute façon - vous n'avez pas inclus suffisamment de code pour commenter spécifiquement).

Modifier pour inclure un commentaire:

Une autre chose à propos de l'utilisation des tables #temp est que si vous devez y ajouter des contraintes, laissez SQL Server générer le nom sinon, même si la table sera unique à la session, la contrainte ne le fera pas et la seconde instance générera une erreur lors de la création de la table.

— Aaron Bertrand
source

Une autre chose à propos de l'utilisation des tables #temp est que si vous devez y ajouter des contraintes, laissez SQL Server générer le nom sinon, même si la table sera unique à la session, la contrainte ne le sera pas et la seconde instance générera une erreur lors de la création de la table.

— Aaron

@Aaron - Suggère de déplacer le commentaire sur les contraintes sans nom dans la réponse. Beaucoup de gens se trompent sur ce détail.

— RLF

Notez également que si quelqu'un ne voulez une table temporaire globale, ils peuvent le déclarer ##likeThis.

— underscore_d

@RLF et Aaron: on peut toujours générer un GUID avec NEWID () et créer la contrainte via Dynamic SQL. Ne pas dire que c'est aussi propre que l'inclure dans l'instruction CREATE TABLE, mais c'est au moins une option. Et je crois également que les contraintes FK ne sont pas autorisées sur les tables temporaires (tant que nous parlons de contraintes de manière générique).

— Solomon Rutzky

@srutzky - Vrai, mais les contraintes nommées sont généralement nommées de manière à faciliter leur référence à partir du code. L'utilisation d'un NEWID () ne fournira pas cette simplification, bien que vous puissiez interroger pour trouver le NEWID si nécessaire.

— RLF