Éviter la méthode de récupération «ligne par ligne» lors du traitement des colonnes LOB source

J'ai une source de base de données PostgreSQL héritée (ODBC) que j'essaie de migrer vers un nouveau schéma SQL Server à l'aide de SSIS. Je reçois un avertissement disant:

La méthode d'extraction «ligne par ligne» est appliquée car la table a des colonnes LOB. Le contenu de la colonne est LOB

Le fait est qu'aucune des colonnes n'a vraiment besoin d'être des LOB. Il y en a quelques-uns qui sont des types TEXT, mais qui pourraient facilement s'intégrer dans un varchar (max). Encore plus étrange, cependant, la plupart sont déjà des varchars, mais il semble que tout ce qui se trouve sur varchar (128) soit traité comme s'il s'agissait d'un LOB (à l'avance, le type de données est DT_NTEXT).

J'ai essayé de faire une commande SQL manuelle où j'ai explicitement casté chaque type de chaîne en un varchar d'une longueur appropriée dans l'instruction select, et ils sont toujours définis comme DT_NTEXT dans la source ODBC.

Je ne suis pas DBA, il est donc tout à fait possible que je fasse quelque chose de vraiment stupide. Je voudrais juste savoir la meilleure façon de garantir que les types se terminent en varchars afin que je puisse récupérer par lots. Des idées?

Au cas où cela importerait, j'utilise SSIS-BI 2014 dans Visual Studio 2013.

Apparemment, cela revient à SSIS traiter tout varchar supérieur à 128 comme NTEXT. Pas certain de pourquoi. Je peux cependant aller dans les propriétés avancées de la source ODBC et changer les types en quelque chose comme DT_WSTR. Ce qui semble fonctionner pour la plupart.

Cependant, j'ai déterminé que quelques-unes des tables avec lesquelles je traite transportent en fait plus de 4000 octets dans certaines de leurs colonnes TEXT, donc je dois malheureusement laisser ces colonnes comme DT_NTEXT pour éviter la troncature (SSIS ne laissera pas vous définissez un type DT_WSTR avec plus de 4000 octets). Je suppose que dans ces cas, je suis juste coincé avec la récupération ligne par ligne, mais au moins j'ai pu corriger quelques tables.

J'ai utilisé la conversion de données pour le varchar supérieur à 128 en tant que NTEXT, mais ce qui a finalement supprimé l'erreur pour moi, c'est l'ensemble Valider les données externes sur Faux.

Cette solution a fonctionné pour moi:

J'ai supprimé l'erreur en modifiant le paramètre Max Varchar dans la propriété de source de données. Allez dans le gestionnaire de connexions. Sélectionnez l'option de génération à côté de la chaîne de connexion. Cliquez sur le bouton de connexion pour accéder à plus d'options. Modifiez la valeur de Max Varchar.

Dans mon cas, la source est Filemaker ODBC qui traite également le texte long comme type de données LOB. Mon package utilisé pour se bloquer pendant une longue période en raison de la baisse extrême des performances de la méthode d'extraction ligne par ligne est appliqué car la table a des colonnes LOB. Ainsi, lors de son déploiement, il expirait après une longue période et échouait finalement.

Je partage la solution réelle qui a fonctionné comme un charme pour moi. Une journée d'une valeur de plus de 30 000 fichiers de type LOB a pris environ 10 minutes pour moi ::

Abaissez le DefaultBufferMaxRows à 1 et augmentez le DefaultBufferSize au maximum, c'est-à-dire 100 Mo. Modifiez ensuite le DSN ODBC source en cochant l'option «traiter le texte en tant que varchar long». Et mappez les types de données tels quels de la source à la cible (sans aucun changement dans l'éditeur avancé de la source).