J'ai un fichier CSV avec un {LF} délimitant chaque ligne et une colonne de date avec le format de date au format "12/20/2010"
(guillemets compris)
Ma colonne de destination est une table de base de données SQL Server 2008 de type date (pas de date/heure)
Dans mon gestionnaire de connexion de fichiers plats, j'ai configuré la colonne de date sur le type de donnéesdate [DT_DATE]
avec TextQualified sur true et le délimiteur de colonne sur{LF}
(il s'agit de la dernière colonne de chaque ligne). Le qualificateur de texte est défini sur"
Lorsque j'essaie de charger ceci dans une destination OLE, j'obtiens l'erreur suivante
[TRN_DORPS [760]] Erreur: code d'erreur SSIS DTS_E_OLEDBERROR. Une erreur de base de données OLE s'est produite. Code d'erreur: 0x80004005 . Un enregistrement de base de données OLE est disponible. Source: "Fournisseur de base de données Microsoft OLE pour SQL Server" Résultat: 0x80004005 Description: "Valeur de caractère non valide pour la spécification de conversion." . [TRN_DORPS [760]] Erreur: Il y avait une erreur avec la colonne d'entrée "" CYCLE_DATE "" (874) sur l'entrée "OLE DB Destination Input" (773). Le statut de colonne renvoyé était: "La valeur n'a pas pu être convertie en raison d'une perte potentielle de données.".
Si j'attache un visualiseur de données, la valeur dans le pipeline est 2010-12-20 00:00:00.0000000
- cette composante de temps est-elle la cause du problème? J'essaie de supprimer le composant de temps avec (DT_DATE)(DT_DBDATE)[CYCLE_DATE]
mais en vain, car il reste le même dans le pipeline
J'ai finalement réussi à résoudre la solution en définissant le type de colonne dans la connexion de fichier à plat de type "date de base de données [DT_DBDATE]".
Apparemment, les différences entre ces formats de date sont les suivantes:
DT_DATE Une structure de date composée de l'année, du mois, du jour, et de l'heure .
DT_DBDATE Structure de date composée de l'année, du mois et du jour.
DT_DBTIMESTAMP Structure d'horodatage composée d'année, mois, heure, minute, seconde et fraction
En modifiant le type de colonne en DT_DBDATE, le problème a été résolu - j'ai joint un visualiseur de données et la valeur CYCLE_DATE était désormais simplement "12/20/2010" sans composant de temps, ce qui a apparemment résolu le problème.
Afin de simuler le problème que vous rencontrez, j'ai créé l'exemple suivant à l'aide de SSIS 2008 R2
avec SQL Server 2008 R2
backend. L'exemple est basé sur ce que j'ai compris de votre question. Cet exemple ne fournit pas de solution, mais il peut vous aider à identifier le problème dans votre cas.
Création d'un fichier CSV simple avec deux colonnes, à savoir le numéro de commande et la date de commande. Comme vous l'avez mentionné dans votre question, les valeurs des deux colonnes sont qualifiées par des guillemets doubles (") et les lignes se terminent par un saut de ligne (\ n), la date étant la dernière colonne. La capture d'écran ci-dessous a été prise avec Notepad ++ , qui peut afficher les caractères spéciaux dans un fichier. LF dans la capture d'écran indique un saut de ligne.
Création d'une table simple nommée dbo.Destination
dans la base de données SQL Server pour renseigner les données du fichier CSV à l'aide du package SSIS. Créer un script pour la table est donnée ci-dessous.
CREATE TABLE [dbo].[Destination](
[OrderNumber] [varchar](50) NULL,
[OrderDate] [date] NULL
) ON [PRIMARY]
GO
Sur le package SSIS, j'ai créé deux gestionnaires de connexions. SQLServer a été créé à l'aide de la connexion de base de données OLE pour se connecter à la base de données SQL Server. FlatFile est un gestionnaire de connexion de fichier plat.
Le gestionnaire de connexions de fichiers plats a été configuré pour lire le fichier CSV et les paramètres sont indiqués ci-dessous. Les flèches rouges indiquent les modifications apportées.
Nom fourni au gestionnaire de connexions de fichiers plats. Naviguez jusqu'à l'emplacement du fichier CSV et sélectionnez le chemin du fichier. Entrez le guillemet double ("
) comme qualificatif. Modification du délimiteur de ligne d'en-tête de {CR} {LF} à {LF}
. Cette modification du délimiteur de ligne d'en-tête est également répercutée sur la section Colonnes.
Aucune modification n'a été apportée dans la section Colonnes.
Changement du nom de la colonne de Column0 à OrderNumber
.
Changement du nom de la colonne de Column1 à OrderDate
et également du type de données à date [DT_DATE]
La prévisualisation des données dans le gestionnaire de connexions de fichiers à plat semble bonne.
Sur l'onglet Control Flow
du package SSIS, placez un Data Flow Task
.
Dans la tâche de flux de données, placez un Flat File Source
et un OLE DB Destination
.
Le Flat File Source
a été configuré pour lire les données du fichier CSV à l'aide du gestionnaire de connexions FlatFile. Trois captures d'écran ci-dessous montrent comment le composant source du fichier à plat a été configuré.
Le composant OLE DB Destination
a été configuré pour accepter les données de Flat File Source et les insérer dans la table de base de données SQL Server nommée dbo.Destination
. Trois captures d'écran ci-dessous montrent comment le composant OLE Destination de base de données a été configuré.
En utilisant les étapes mentionnées dans les 5 captures d'écran ci-dessous, j'ai ajouté un visualiseur de données sur le flux entre la source de fichier à plat et la destination de base de données OLE.
Avant d'exécuter le package, j'ai vérifié les données initiales présentes dans le tableau. Il est actuellement vide parce que j'ai créé cela en utilisant le script fourni au début de ce post.
Exécuté le package et son exécution a été suspendue temporairement pour afficher les données provenant de la source de fichier à plat vers la destination de la base de données OLE dans la visionneuse de données. J'ai cliqué sur le bouton Exécuter pour poursuivre l'exécution.
Le package a été exécuté avec succès.
Les données source du fichier plat ont été insérées avec succès dans la table dbo.Destination
.
Voici la mise en page de la table dbo.Destination. Comme vous pouvez le constater, le champ OrderDate est du type de données date et le package a quand même continué à insérer les données correctement.
Ce post même si n'est pas une solution. J'espère que cela vous aidera à découvrir où le problème pourrait se situer dans votre scénario.
Le type de données approprié pour la valeur "2010-12-20 00: 00: 00.0000000" est DATETIME2 (7) / DT_DBTIME2 ().
Mais le type de données utilisé pour le champ CYCLE_DATE est DATETIME - DT_DATE . Cela signifie précision en millisecondes avec précision jusqu’à une milliseconde (aaaa-mm-jjThh: mi: ss.mmL, où L peut être égal à 0,3 ou 7).
La solution consiste à remplacer le type de date CYCLE_DATE par DATETIME2 - DT_DBTIME2.