Discussion :

[Morbius]

Bonjour à tous.

Je relance un poste concernant la suite de mes péripéties avec SSIS. (lien vers le sujet précédent)

L'idée, pour résumer, est de récupérer des données dans une base Informix concernant les appel de la hotline de l'entreprise (système Cisco).
Pour cela j'ai installé et configurer le pilote ODBC fourni par IBM. Cela m'a pris un peu de temps mais ça fonctionne et lors du test de la connexion dans le gestionnaire de sources ODBC il n'y a pas d'erreur.
De plus dans Visual Studio, quand j'utilise l'outil de connexion à une base de données, j'arrive à voir les table et interroger la base.

C'est là que les choses ce compliquent. Fier de moi je me dis que j'allais faire une test avec une tâche de flux de données, mais quand je configure les propriétés, malgré le fait qu'en mode d'accès 'tables/vues' je vois les tables de la base je me retrouve avec l'erreur suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Impossible de se connecter au composant source.
 
Erreur 0xc0047062: Source - agentconnectiondetail [1]: System.Data.Odbc.OdbcException: ERROR [42000] [Informix][Informix ODBC Driver][Informix]A syntax error has occurred.
   à System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
   à System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object[] methodArguments, SQL_API odbcApiMethod)
   à System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)
   à System.Data.Odbc.OdbcCommand.ExecuteReader(CommandBehavior behavior)
   à System.Data.Odbc.OdbcCommand.ExecuteDbDataReader(CommandBehavior behavior)
   à System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
   à Microsoft.SqlServer.Dts.Pipeline.DataReaderSourceAdapter.ReinitializeMetaData()
   à Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostReinitializeMetaData(IDTSManagedComponentWrapper100 wrapper)
 
------------------------------
INFORMATIONS SUPPLÉMENTAIRES*:
 
ERROR [42000] [Informix][Informix ODBC Driver][Informix]A syntax error has occurred. (iclit09b.dll)
 
------------------------------

D'après les recherches que j'ai fait cela pourrait venir d'un problème de conversion. Seulement je bloque ici et Google a beau être mon ami, il n'est pas omniscient .

Est-ce que quelqu'un a déjà expérimenté ce problème et aurait une solution ou une piste sur laquelle m'orienter ?

Merci, bonne journée.

[Jinroh77]

Bonjour,
Je ne suis pas allé faire de recherche par rapport à cette erreur et le driver ODBC en particulier.

Au moment d'obtenir cette erreur, es-tu bien dans Visual Studio, en train de développer ton package.
Est-ce pendant une demande d'aperçu des données ou à l’exécution ?

La liste des tables s'affiche bien, mais le composant de source est-il alors utilisé avec le nom de la table ou un "select ... from Table" ? Essaie alors les 2 méthodes.

Enfin, en parlant d'un "problème de conversion", il peut y avoir un problème au niveau du CodePage, mais cela implique plutôt des problème dans le format des données, pas une erreur de connexion.

[Morbius]

Oui je suis bien dans Visual Studio et l'aperçu ne se génère pas. L'erreur qui apparaît quand je clique sur Aperçu est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ERROR [42000] [Informix][Informix ODBC Driver][Informix]A syntax error has occurred. (iclit09b.dll)

J'ai vraiment du mal à comprendre cette histoire d'erreur de syntaxe.

Je ne peux pas exécuter le package car aucune donnée n’apparaît en sortie de la source ADO .NET et donc je ne peux pas remplir le fichier de destination. J'ai essayé de le paramétrer à la fois avec le nom de la table directement et aussi avec une requête SQL en vain.

Concernant le code page, la base Informix est en UTF8 et si je ne dis pas de bêtises SQL Server a un peu de mal avec ce format.
Pour le problème de conversion je pensais surtout aux dates qui peuvent être de plusieurs types différents sous Informix (DATE, DATETIME ne contenant que le jour, l'année, les secondes...), pour chaque niveau de précision il y a un type.

[Jinroh77]

A tout hasard, et ce ne serait pas très propre, si vous créez un serveur lié sur votre base MS SQL vers cette autre base en utilisant le driver ODBC, est-ce que vous parvenez à interroger cette base via SSMS ?

Sinon, effectivement, bizarre cette erreur de syntaxe.

[Morbius]

Je ne peux pas lier la base dans SSMS car mon admin système ne m'a pas donné les droits, je pourrai tester ça demain si il est là. En revanche en utilisant l'utilitaire de connexion à une base de données dans Visual Studio je peux l'interroger. Serait-il possible en passant par cet utilitaire d'arriver à quelque chose ?

[Jinroh77]

Plutôt qu'un composant source ADO.Net, avez-vous essayé d'autres composant ?
Concernant l'outil de connexion de BDD de Visual, il ne fait qu'utilisant le driver dans une couche comme le font les composants sources.

[Morbius]

Oui j'ai testé tout ce qui était testable avant de lancer ce sujet, à chaque fois c'est la même erreur qui se présente.
Il faut espérer que le fait de lier le serveur dans SSMS va changer la donne sinon je suis bon pour passer par la porte de derrière et faire mes importations de façon un peu moins propre avec un script en VB par exemple.

[Morbius]

J'ai réussi à configurer le serveur lié vers la base Informix mais dans SSMS je ne peux pas voir les données. Les tables apparaissent mais une nouvelle erreur apparait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Le fournisseur OLE DB "MSDASQL" du serveur lié "CISCO" a retourné le message "[Informix][Informix ODBC Driver][Informix]A syntax error has occurred.".
Msg*7321, Niveau*16, État*2, Ligne*1
Une erreur s'est produite lors de la préparation de l'exécution de la requête "select * from "Informix"."areacode"" sur le fournisseur OLE DB "MSDASQL" du serveur lié "CISCO".

Toujours cette histoire d'erreur de syntaxe, ça fait un peu Bad Wolf dans Doctor Who, le truc qui est partout et qui annonce la fin de l'univers (univers BO en l'occurence )

Plus sérieusement dans les propriétés de sécurité j'ai mappé mon compte de domaine pour qu'il utilise le compte de la base Informix mais rien n'y fait.
Je commence un peu à désespérer malgré le fait que ça avance (doucement mais surement) alors que je suis un débutant sur les outils de M$ et en BI.

[Jinroh77]

Hummm du coup, un peu moins que du pur BI, c'est une erreur d'utilisation de l'ODBC
Au cas où, avez-vous essayé avec d'autres syntaxe, en supprimant le nom de la base, ajoutant un shéma etc. ?

[Morbius]

Salut tout le monde.

Je relance le sujet pour signaler que j'ai enfin trouver le temps de travailler sur ce problème d'importation depuis une source ODBC.

Après avoir passer pas mal de temps sur internet à la recherche d'une solution j'ai résolue mon problème.
L'origine de ce problème est dû au framework .NET 2.0SP2 et 3.5SP1 (lien vers le KB).
SSIS est très pointilleux sur les types de données et n'aime pas que l'on importe des données de type caractères unicode dans l'état. Il faut les traiter avant de les insérer dans la base.

Pour la petite explication la procédure à suivre est la suivante:

- écrire la requête à la main pour lire les données depuis le pilote dans un module source ADO NET (l'accès en mode table ou vue ne fonctionne pas avec une source ODBC)
- si vous avez des attributs type nvarchar vous entrez dans l'éditeur avancé de la source de donnée et modifiez pour chaque attribut type DT_WSTR, DT_NTEXT, DT_BYTES ou DT_IMAGE la valeur de ErrorRowDisposition et TruncationRowDisposition et la passez à RD_RedirectRow. Ceci fait vous redirigez la sortie d'erreur vers un fichier ou ce que vous voulez.
- ensuite vous envoyez vos données dans un module "colonne dérivée" et y transformez les attributs de type cités au dessus avec les fonctions de cast correspondantes.
- l'étape suivante consiste à utiliser, toujours pour ces attributs récalcitrants, un module de conversion de données.
- enfin vous envoyez tout dans la base à remplir.

Tout ça n'est pas à faire si la table ne contient pas les quatre types précédents.

Résultat l'ODS est de nouveau sur les rails et mes rapports BO vont pouvoir repartir