Page 1 sur 1

Connexion d'une application Windows sur DB2 AS400 ?

Posté : lun. 19 mai 2008, 13:57:36
par gom
Bonjour à tous,

Je cherche depuis plusieurs jours ... je sens que je suis près du but, mais je n'y arrive pas ! :cry:

Une société extérieure a créé pour la boîte dans laquelle je travaille, une application Windows qui doit se connecter à l'une de nos BdD DB2 hébergée sur AS400 (V5R4).

Mais le problème est que cette application essaye de se connecter à notre BdD via ADO (http://fr.wikipedia.org/wiki/ActiveX_Data_Objects ; http://support.microsoft.com/kb/183606).

J'ai bien trouvé des informations pour la connexion via ADO sur une BdD DB2 AS400, mais je ne vois pas où il est écrit : cliquer ici et hop ça marchera !!!

Bref, je suis perdu dans tout ça et je ne sais pas vraiment ce qu'il faut faire ! :?


Une idée ?

Gôm

ADO

Posté : lun. 19 mai 2008, 14:45:33
par cmasse
il fait installer le driver qui va bien sur le poste client.


Il est, par exemple livré avec le produit iSeris Access (sur les CD ou dans le répertoire automatiquement partagé "/QIBM/ProdData" de l'AS/400)


Le serveur lui est automatiquement démarré et correspond aux travaux nommés QZDASOINIT.



bon courage.


Christian

(sans texte)

Posté : mar. 03 juin 2008, 09:36:12
par gom
Merci pour ta réponse ! :D


Effectivement en utilisant la chaîne de connexion suivante :

Code : Tout sélectionner

Driver={iSeries Access ODBC Driver};System=Nom_BDD
au lieu de :

Code : Tout sélectionner

Provider=IBMDADB2;dsn=Nom_BDD
ça fonctionne !


J'ai trouvé cette chaîne de connexion ici :

http://www.connectionstrings.com/?carrier=as400


Gôm

(sans texte)

Posté : mar. 03 juin 2008, 09:42:22
par gom
Mon problème de connexion est résolu, par contre, je n'arrive pas à récupérer un fichier stocké en BdD.

J'insère un fichier ZIP dans un champ BLOB via une application de test qui ne génère pas d'erreur à l'insertion, par contre, on est incapable de récupérer le fichier mis en BdD, là, l'application génère une erreur.
An Error Occured
ADO Error Code = 80040e21
Msg: IDispatch error #3105
Source: Microsoft OLE DB Provider for ODBC Drivers
Description: Une opération OLE-DB en plusieurs étapes a généré des erreurs. Vérifiez chaque valeur d'état OLE-DB disponible. Aucun travail n'a été effectué.

L'insertion fonctionne aussi bien en DB2 AS400 (V5R4) que sur une BdD DB2 Windows (v.9) pour peu que l'on utilise des chaînes de connexion différentes ... forcément !

Je suis sûr que l'insertion fonctionne puisque l'on voit bien, lorsque l'on fait une requête SELECT, le ZIP en Hexadécimal dans notre champ en BdD.

Une idée ?

(sans texte)

Posté : mar. 03 juin 2008, 11:10:06
par gom
Bon, on a continué à chercher et apparemment le problème viendrait de la méthode getChunk() qui ne serait pas "capable" de récupérer notre ZIP stocké dans notre champ de type BLOB de notre BdD DB2 AS400, alors qu'elle l'est sur une BdD DB2 Windows ! :?


Est-il possible que cela ne vienne pas tant du fait que l'on soit sur AS400 ou Windows, mais plutôt du fait que l'on utilise des drivers différents pour s'y connecter ?


:arrow: AS400 :

Code : Tout sélectionner

Driver={iSeries Access ODBC Driver};System=Nom_BDD
ou

Code : Tout sélectionner

Driver={Client Access ODBC Driver (32-bit)};System=Nom_BDD

:arrow: Windows :

Code : Tout sélectionner

Provider=IBMDADB2;dsn=Nom_BDD

ADO et BLOB

Posté : mar. 03 juin 2008, 15:20:51
par cmasse
Bonjour,

Attention la chaine de connexion

Code : Tout sélectionner

Driver={iSeries Access ODBC Driver};System=Nom_BDD
connecte en ODBC ,
la chaîne

Code : Tout sélectionner

Provider=IBMDAxxx ...
connecte en OLE DB.

par contre Driver={iSeries Access ODBC Driver} et Driver={Client Access ODBC Driver (32-bit)} représentent en fait le même Driver , avec effectivement une ancienne signature, mais qui pointe sur le même exécutable, pas de soucis.



en quel langage est écrit l'application cliente ?

je trouve des références comme celle-ci en VB

http://www.vbfrance.com/infomsg_ERREUR- ... 01413.aspx et des bugs référencés en DELPHI concernant les BLOB.


difficile d'en dire plus, n'ayant pas rencontré cette erreur.