[MSSQL] table temporaire et procedure stockee

table temporaire et procedure stockee [MSSQL] - SQL/NoSQL - Programmation

Marsh Posté le 19-01-2005 à 17:14:07    

Bonjour,
 
j'ai une procédure stockée dans laquel j'extrais certaines données dans une table temporaire :
 

Code :
  1. SELECT TOP 39 fDate
  2. INTO    #tmpRecentRepMsg
  3. FROM    Messages
  4. WHERE   fRepondeur = @sRepondeur
  5. ORDER BY fDate DESC


 
Il y a ensuite différents traitements sur la table #tmpRecentRepMsg et je la Drop à la fin de la procédure.
 
Est-ce qu'il n'y a pas de risque d'accès concurrent à la table temporaire si la procédure est appelée plusieurs fois simultanément ? Du genre 15 connections sur un serveur multiprocesseur.
 
J’aurai bien utilisé un DECLARE @tmpRecentRepMsg table, mais à priori on ne peut pas faire de SELECT INTO avec.
 
Merci


---------------
http://www.ikimegon.com/
Reply

Marsh Posté le 19-01-2005 à 17:14:07   

Reply

Marsh Posté le 21-01-2005 à 12:07:23    

Suffit de lire la doc...
 

Citation :


Tables temporaires
Vous pouvez créer des tables temporaires locales et globales. Les tables temporaires locales ne peuvent être vues que dans la session en cours ; les tables temporaires globales sont accessibles dans toutes les sessions.
 
Faites précéder les noms de tables temporaires locales d'un signe dièse (#table_name), et les tables temporaires globales de deux signes dièse (##table_name).
 
Les instructions SQL font référence à une table temporaire à l'aide de la valeur spécifiée pour table_namedans l'instruction CREATE TABLE :
 
CREATE TABLE #MyTempTable (cola INT PRIMARY KEY)
INSERT INTO #MyTempTable VALUES (1)
 
Si vous créez une table temporaire locale dans une procédure stockée ou dans une application qui peut être exécutée en même temps par plusieurs utilisateurs, SQL Server doit être capable de distinguer les tables créées par les différents utilisateurs. Cela est géré par SQL Server en ajoutant de manière interne un suffixe numérique à chaque nom de table temporaire locale. Le nom complet d'une table temporaire, tel qu'il est stocké dans la table sysobjects de tempdb, est constitué du nom de table spécifié dans l'instruction CREATE TABLE plus le suffixe numérique généré par le système. Pour laisser assez de place au suffixe, le table_name spécifié pour un nom de table temporaire locale ne doit pas dépasser 116 caractères.
 
Les tables temporaires sont automatiquement supprimées lorsqu'elles deviennent hors de portée, sauf si elles sont supprimées explicitement à l'aide de DROP TABLE.  
 
Une table temporaire locale créée dans une procédure stockée est supprimée automatiquement lorsque la procédure stockée est terminée. La table peut être référencée par des procédures stockées imbriquées exécutées par la procédure stockée qui a créé la table. La table ne peut pas être référencée par le processus qui a appelé la procédure stockée ayant créé la table.
 
 
Toutes les autres tables temporaires locales sont supprimées automatiquement à la fin de la session en cours.
 
 
Les tables temporaires globales sont supprimées automatiquement lorsque la session qui a créé la table se termine, et que toutes les autres tâches n'y font plus référence. L'association entre une tâche et une table n'est assurée que pendant la durée d'une seule instruction Transact-SQL. Cela signifie qu'une table temporaire globale est supprimée à la fin de la dernière instruction Transact-SQL qui faisait activement référence à la table lorsque la session de création s'est terminée.  
Une table temporaire locale créée au sein d'une procédure stockée ou d'un déclencheur est différente d'une table temporaire ayant le même nom créée avant l'appel de la procédure stockée ou du déclencheur. Si une requête fait référence à une table temporaire, et que deux tables temporaires existent à ce moment sous le même nom, la table à laquelle la requête fait référence n'est pas définie. Les procédures stockées imbriquées peuvent également créer des tables temporaires portant le même nom qu'une table temporaire créée par la procédure stockée qui l'a appelée. Toutes les références au nom de table dans la procédure stockée imbriquée sont résolues par rapport à la table créée dans la procédure imbriquée, par exemple :
 
CREATE PROCEDURE Test2
AS
CREATE TABLE #t(x INT PRIMARY KEY)
INSERT INTO #t VALUES (2)
SELECT Test2Col = x FROM #t
GO
CREATE PROCEDURE Test1
AS
CREATE TABLE #t(x INT PRIMARY KEY)
INSERT INTO #t VALUES (1)
SELECT Test1Col = x FROM #t
EXEC Test2
GO
CREATE TABLE #t(x INT PRIMARY KEY)
INSERT INTO #t VALUES (99)
GO
EXEC Test1
GO
 
Voici le jeu de résultats obtenu :
 
(1 row(s) affected)
 
Test1Col    
-----------  
1            
 
(1 row(s) affected)
 
Test2Col    
-----------  
2            
 
Lorsque vous créez des tables temporaires locales ou globales, la syntaxe CREATE TABLE prend en charge les définitions de contraintes à l'exception des contraintes FOREIGN KEY. Si vous spécifiez une contrainte FOREIGN KEY dans une table temporaire, l'instruction renvoie un message d'avertissement précisant que la contrainte a été ignorée et que la table est toujours créée mais sans les contraintes FOREIGN KEY. Les tables temporaires ne peuvent pas être référencées dans des contraintes FOREIGN KEY.
 
Considérons l'utilisation de variables de tables au lieu de tables temporaires. Les tables temporaires sont utiles lorsque des index doivent être créés explicitement sur ces tables ou lorsque les valeurs de tables doivent être visibles au travers de plusieurs procédures stockées ou fonctions. En général, ces variables de tables contribuent à un traitement plus efficace des requêtes. Pour plus d'informations, voir table.


Message édité par Arjuna le 21-01-2005 à 12:07:37
Reply

Marsh Posté le 21-01-2005 à 12:46:09    

Arjuna a écrit :

Suffit de lire la doc...


 
Merci pour la doc en francais. Sur l'anglaise, tout ce que j'ai sur ce point c'est :
 

Citation :

Local temporary tables have a single number sign (#) as the first character of their names; they are visible only to the current connection for the user; and they are deleted when the user disconnects from instances of Microsoft SQL Server 2000


---------------
http://www.ikimegon.com/
Reply

Marsh Posté le 21-01-2005 à 14:21:21    

Ben ça veut dire la même chose :
-> Visible que pour l'utilisateur de la connection courrante.
 
A moins de faire des requêtes assynchrones en utilisant la même connection (ce qui est à mon avis nullement ton cas), en aucun cas tu peux avoir de conflit. Et même dans ce cas, étant donné en effet l'ajout dans la doc à propos des PS, même dans ce cas précis, les tables temporaires sont cloisonnées.

Reply

Marsh Posté le 21-01-2005 à 17:07:54    

Arjuna a écrit :


A moins de faire des requêtes assynchrones en utilisant la même connection...


 
Ben si je crois : j'utilise un soft qui fait une connexion 'partagee' (je ne sais pas exactement ce qu'ils entendent par la) vers un serveur. Derriere, il y a de 1 a 100 threads qui font du SQL.
 
Donc avec la precision, je suis rassure, quel que soit le bazar en dessous.
 
Merci


---------------
http://www.ikimegon.com/
Reply

Marsh Posté le 21-01-2005 à 17:26:55    

La connection partagée ne pose pas de problème. La connection est indénependante de la session.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed