2009-06-04 10 views
0

j'ai une table temporaire, qui ne va pas disparaître. Je veux voir ce qu'il y a dans le tableau pour déterminer quelles sont les mauvaises données qui s'y trouvent. Comment puis-je voir les données dans la table temporaire?Exporter les données/Vue d'une table temporaire SQL Server

Je peux le voir dans tempdb. J'ai couru

SELECT * FROM tempdb.dbo.sysobjects WHERE Name LIKE '#Return_Records%' 

pour obtenir le nom de la table.

Je peux le voir est des colonnes et son ID d'objet dans

select c.* 
from tempdb.sys.columns c 
inner join tempdb.sys.tables t ON c.object_id = t.object_id 
where t.name like '#Return_Records%' 

Comment puis-je obtenir les données?

D'ailleurs, cela ne fonctionne pas

SELECT * FROM #Return_Records 
+0

Quelle version de SQLServer utilisez-vous? –

+0

sql server 2005 –

+0

Votre problème semble être que "ça ne s'en va pas". Vous combattez une caractéristique de conception intentionnelle de base du logiciel. (Cela ressemble à une mauvaise décision de conception politiquement sensible impliqué ici.) – dkretz

Répondre

1

Une façon d'obtenir les données dans un bas niveau et pas particulièrement facile à manipuler de manière consiste à utiliser la commande PAGE DBCC comme décrit dans un billet de blog par Paul Randal:

http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/10/625659.aspx

Vous devrait être capable de trouver le fichier et le numéro de page de la première page dans l'objet en interrogeant sur sysindexes .. la dernière fois que je l'ai fait était sur SQL Server 7.

Si les données sont dans la base de données, alors la page DBCC sera en mesure de le vider.

pjjH

+0

Je viens d'obtenir ma copie de http://www.amazon.com/Microsoft%C2%AE-SQL-Server%C2%AE-2008-Internals/dp/0735626243 qui a un chapitre sur DBCC écrit par Paul Randal. J'espère pouvoir suivre avec des exemples exécutables. –

+0

CREATE table #foo (i entier, t varchar (max)) INSERT #foo (i, t) VALEURS (42, 'ceci n'est pas une banane') dbcc ind ('tempdb', '#foo', - 1) Page DBCC ('tempdb', 1, 210, 3) TABLERESULTS [-] emplacement 0 Décalage 0x60 Longueur 35 \t vidage de la mémoire @ 0x417DC060 \t \t 00000014: 6973206e 6f742061 2062616e 616e61 †††††††† ††††† est pas une banane emplacement 0 Offset 0x60 Longueur 35 \t emplacement 0 Colonne 1 Décalage 4 Longueur Longueur 0x4 (physique) 4 \t i emplacement 0 offset 0x60 Longueur 35 \t t = [BLOB Inline données] slot 0 Colonne 2 Offset 0xf Longueur 20 Longueur (physique) 20 \t \t 417D13D4: 74686973 20697320 6e6f7420 61206261 6e616e61 † Ceci n'est pas une banane –

+0

Désolé pour la mise en forme de borked dans le commentaire précédent. La procédure documentée à http://www.mssqltips.com/tip.asp?tip=1578 fonctionne pour moi. Je n'étais pas au courant de DBCC IND. –

0

C'est quelque chose qui ressemble à vous évidemment essayé, mais comme vous ne l'avez pas mentionné je pensais que je voudrais mentionner juste au cas où:

Avez-vous essayé "SELECT * FROM #Return_Records"?

+3

cela ne fonctionne pas, j'ai certainement essayé ce premier –

1

limites SQL Server accès aux tables locales Temp (de #TableName) à la connexion qui a créé la table. Les tables temporaires globales (## TableName) peuvent être accessibles par d'autres connexions tant que la connexion qui l'a créée est toujours connectée.

Même si vous pouvez voir le tableau dans le catalogue de la table, il n'est pas accessible en essayant de faire un SELECT. Il vous donne une erreur "nom d'objet invalide".

Il n'existe aucun moyen documenté d'accéder aux données dans les tables temporaires locales créées par d'autres connexions. Je pense que vous pourriez ne pas avoir de chance dans ce cas.

+0

Ce que je savais ... mais j'espérais qu'il y avait un moyen non documenté pour obtenir les données . Si les données sont présentes dans la base de données, il doit y avoir quelqu'un pour y parvenir. –

0

Comme José Basilio dit, c'est une table temporaire appartenant à une autre connexion. S'il existe depuis longtemps, il doit appartenir à une connexion ouverte depuis longtemps. Vérifier la maintenance -> Moniteur d'activité; vous pouvez trier par heure de connexion.

Vérifiez si l'heure de connexion ou le dernier délai de traitement correspond à la date de création de la table temporaire. Cela peut être récupérée avec:

select crdate from tempdb.dbo.sysobjects WHERE Name LIKE '#Return_Records%' 

Vous pouvez abattre les connexions suspectes (. Clic droit et Kill Process) Si la table est parti après avoir tué un processus, vous avez trouvé le coupable.

Pour simplement supprimer la table, redémarrez le service SQL Server. Vous pouvez attacher un profileur SQL juste après avec un filtre pour commencer à rechercher la connexion qui crée la table temporaire.

Questions connexes