J'utilise une table temporaire dans la procédure stockée dans SQL Server. J'essaie d'utiliser ce SP dans l'éditeur source OLE DB. P>
Je peux voir que la sortie de données est renvoyée dans le constructeur de requête fourni avec le bouton de la requête de construction. Mais lorsque je clique sur l'onglet Colonnes, je reçois l'erreur ci-dessous. P>
- Titre: Microsoft Visual Studio H2>
Erreur lors de la tâche de flux de données [Source OLE DB [1]]: code d'erreur SSIS DTS_E_OLEDBERROR. Une erreur OLE DB s'est produite. Code d'erreur: 0x80004005. Un enregistrement OLE DB est disponible. Source: "Microsoft SQL Serveur Native Client 10.0 "HRESULT: 0x80004005 Description:" Invalide Nom d'objet '## Paiement'. ". p>
Erreur lors de la tâche de flux de données [Source OLE DB [1]]: Impossible de récupérer la colonne informations de la source de données. Assurez-vous que votre table cible dans le La base de données est disponible. p> blockQuote>
Cela signifie-t-il que je ne peux pas utiliser de tables Temps dans SP, si je veux que cela soit consommé par SSIS P>
7 Réponses :
Nope, c'est une question d'autorisations. Cela devrait vous aider: P>
j'ai utilisé p>
SET FMONLY OFF Au début de la procédure, qui ne dira pas de traiter des lignes au client quand il n'est pas exécuté Comme il n'y a pas de table Temp tout en analysant le SP, d'où aucune colonne n'est disponible tout en analysant. P>
Cela m'a fait fonctionner enfin :) p>
J'ai essayé cela, mais quand je vais diriger le colis en SSIS, il gèle et prend pour toujours avant de commencer le traitement. Si je supprimai Set Fmtonly Off et revenez à une variable de table au lieu d'une table TEMP, le paquet commence bien.
Vous souhaitez éviter d'utiliser cela à tout prix, à moins que la performance ne soit jamais une question. Cela peut provoquer la course à votre procédure stockée jusqu'à 5 fois au lieu d'une fois.
Si l'erreur a été soulevée pendant que vous êtes dans les offres, la solution AJDAMS ne fonctionnera pas car elle ne s'applique qu'aux erreurs soulevées lors de l'exécution du package à partir de l'agent SQL Server. P>
Le problème principal est que les SSI luttent pour résoudre les métadonnées. Depuis son point de stand, les tables ## n'existent pas car il ne peut pas renvoyer les métadonnées pour l'objet pendant la phase de pré-exécution. Vous devez donc trouver un moyen de satisfaire à ses besoins que le tableau existe déjà. Il y a quelques solutions: p>
n'utilisez pas de tables temporaires. Au lieu de cela, créez une base de données de travail et mettez tous vos objets dedans. Évidemment, cela ne fonctionnera probablement pas si vous essayez d'obtenir les données sur un serveur où vous n'êtes pas un DBO comme un serveur de production, vous ne pouvez donc pas compter sur cette solution. P> LI>
Utilisez CTE's au lieu de tables temporaires. Cela fonctionne si votre serveur source est 2005/2008. Cela ne vous aidera pas si le serveur source est de 2000. P> li>
Créez la table ## dans une commande SQL SQL distincte. Définissez la propriété ReSeSameconnection de la connexion à True. Définissez DelayValidation sur TRUE pour le flux de données. Lorsque vous configurez le flux de données, faites-le simuler en ajoutant temporairement un champ TOP 0 SELECT = CAST (NULL AS INT) dans le haut de la procédure stockée contenant des métadonnées identiques à votre sortie finale. N'oubliez pas de supprimer cela de la procédure stockée avant d'exécuter le package. C'est également un tour pratique pour partager des données de table temporaires entre les flux de données. Si vous souhaitez que le reste du colis utilise des connexions distinctes de manière à pouvoir fonctionner en parallèle, vous devez créer une connexion non partagée supplémentaire. Cela échappe au problème car la table temporaire existe déjà au moment où les tâches de flux de données sont exécutées. P> LI> ol>
L'option 3 atteint votre objectif, mais il est compliqué et la limitation que vous devez séparer la commande ## dans un autre appel de procédure stockée. Si vous avez la possibilité de créer des procédures stockées sur le serveur source, vous avez probablement la possibilité de créer d'autres objets tels que les tables de stockage et c'est généralement une meilleure solution. Il s'agit également des étapes secondaires possibles des problèmes de contention tempdb qui est également un avantage souhaitable. P>
bonne chance et laissez-moi savoir si vous avez besoin d'orientations supplémentaires sur la mise en œuvre de l'étape 3. P>
Vous pouvez utiliser des variables de table au lieu de tables temporaires. Cela fonctionnera p>
Oui, c'est l'option que j'ai gardée si celle-ci n'aurait pas travaillé :)
Mais comment la table TEMP va vous aider à mieux vous aider à mieux être le cas si vous envisagez d'utiliser l'indexation de la table Temp
C'est une option, mais les variables de table n'ont pas de statistiques disponibles.
Pour tous les tracas impliqués, je pense que ce n'est probablement pas la peine. Créez une table vraie dans la DB et tronquez-la avant / après votre charge. Si c'est pour une datawarehouse, cela ne va pas importer si vous avez une table supplémentaire ou deux. Cela vous donne les outils SSIS du temps de conception et signifie que vous n'avez pas à vous soucier des intracacées des tables Temps.
Si vous voulez garder les choses séparées, créez simplement vos tables Temps SSIS dans un schéma séparé. Vous pouvez utiliser des autorisations pour rendre ce schmema invisible à tous les autres utilisateurs. P>
CREATE SCHEMA [ssis_temp] CREATE TABLE [ssis_temp].[tempTableName]
Cet article a été superbed par Comment exécuter une procédure stockée à partir de SSIS pour obtenir sa sortie au fichier texte
Cela décrit comment exécuter une procédure stockée à partir de SSIS CREATE PROCEDURE [dbo] . [GenMetadata] AS
SET NOCOUNT ON
IF 1 = 0
BEGIN
-- Publish metadata
SELECT CAST (NULL AS INT ) AS id ,
CAST (NULL AS NCHAR ( 10 )) AS [Name] ,
CAST (NULL AS NCHAR ( 10 )) AS SirName
END
-- Do real work starting here
CREATE TABLE #test
(
[id] [int] NULL,
[Name] [nchar] ( 10 ) NULL,
[SirName] [nchar] ( 10 ) NULL
)
C'est la solution standard et de loin les plus faciles à mettre en œuvre. Il n'est pas nécessaire de créer d'autres objets de base de données ou d'éviter d'utiliser des procédures stockées.
D'après ce que j'ai vu, c'est la meilleure solution. SET FMONLY OFF CODE> TUERS Performances, les variables de table ne sont pas toujours appropriées, pas de mess avec
retardvalidation code>, et cela fonctionne avec SQL 2000 (comme je devais malheureusement le savoir). J'ai constaté que vous pouvez mettre la requête factice en dehors de la PROC stockée et dans la composante source, alors gardez votre processus intact et plus propre. par exemple.
si 1 = 0 commencez sélectionnez Cast (null comme int) comme foo end; EXEC UDPMYPROC CODE> Je n'avais pas besoin
Set Nocount code> en haut de la déclaration (bien que mon procédé soit défini)
Ces étapes m'a aidé:
Recomposez l'appel de votre SP de p>
EXECT P_MYSPWIPTABLES?,? P> LI> ol>
dans p>
@sriram pense que vous pouvez également vérifier le lien ci-dessous pour plus de détails, c'est une astuce que je ne sais pas pourquoi Microsoft gars le rend plus simple ... - SQLLIKE.COM /USE-TEMPORARY-TABLE-WITH-SIS-40.HTML