8
votes

Utilisation de tables Temps dans SSIS

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.

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.

- Titre: Microsoft Visual Studio

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'. ".

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.

Cela signifie-t-il que je ne peux pas utiliser de tables Temps dans SP, si je veux que cela soit consommé par SSIS


1 commentaires

@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


7 Réponses :


3
votes

Nope, c'est une question d'autorisations. Cela devrait vous aider:

http://support.microsoft.com/kb/933835


0 commentaires

8
votes

j'ai utilisé

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.

Cela m'a fait fonctionner enfin :)


2 commentaires

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.



6
votes

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.

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:

  1. 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.

  2. 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.

  3. 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.

    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.

    bonne chance et laissez-moi savoir si vous avez besoin d'orientations supplémentaires sur la mise en œuvre de l'étape 3.


0 commentaires

0
votes

Vous pouvez utiliser des variables de table au lieu de tables temporaires. Cela fonctionnera


3 commentaires

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.



1
votes

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]


0 commentaires

18
votes

Mise à jour de novembre 2020. strong>

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 
    ) 


2 commentaires

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 TUERS Performances, les variables de table ne sont pas toujours appropriées, pas de mess avec retardvalidation , 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 Je n'avais pas besoin Set Nocount en haut de la déclaration (bien que mon procédé soit défini)



1
votes

Ces étapes m'a aidé:

  1. Écrivez le résultat final défini dans une table.
  2. script qui tableau comme créer une nouvelle fenêtre Nouvelle éditeur de requête.
  3. Enlevez tout, à l'exception des supports ouverts et fermés qui définissent les colonnes.
  4. enveloppez cela dans une autre paire de supports.
  5. Recomposez l'appel de votre SP de

    EXECT P_MYSPWIPTABLES?,?

    dans xxx


0 commentaires