|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre chevronné
![]() ![]() Inscription : mai 2007 Messages : 562 ![]() |
Bonjour,
Nous utilisons une base DB2 sur AS400 qui n'est pas en Unicode. Bien logiquement, à chaque fois que l'on a des caractères spéciaux, c'est pas simple à résoudre. Cette fois, j'ai des caractères polonais à extraire via Iseries Data Transfer. Le probleme est que je n'arrive pas à voir ces caracteres ni dans Client Access, ni dans notre appli windows d'interface. Pourtant, les personnes qui les ont rentré les voient à l'écran et arrivent à les sortir en spool. Ce que je voudrais, c'est extraire donc c'est données en .csv en ayant les bon caracteres. J'ai essayé de modifier les CCSID un peu partout (mon profil, le data transfer...) mais sans succès, j'obtiens toujours des caracteres de remplacement. Chose étrange, a priori, le code CCSID pour le polonais est 870 (qui me sort du grand n'importe quoi) mais les utilisateurs ont 1153 Latin-2 qui me sort tous les caracteres sauf les caracteres speciaux. J'ai essayé avec des variantes mais toujours sans succès. Si quelqu'un a une idée, ce serait vraiment cool. A noter, je ne peux pas vraiment agir sur le fichier source de DB2, il est généré par un profil générique, donc sans code particulier et chose très étrange, pour saisir des caracteres polonais dans Client Access, les utilisateurs utilisent une vieille version (5.3 je crois) mais ca ne marche pas sur les version postérieures. Merci d'avance |
|
|
00
|
|
|
#2 |
|
Membre Expert
![]() ![]() |
Bonjour.
J'ai des AS400 (V4R4 et V5R4) chez des clients qui utilisent l'Arabe sans que ce soit une langue secondaire. - Avec Client Access ancienne et nouvelle versions on n'a pas de problème de saisie si la session 5250 est bien configurée : code page config, et clavier. - Pour le problème du transfert (et généralement les accès ODBC et autres tel que windev), il faut utiliser le bon CCSID (870 dans ton cas) sans chambouler le CCSID par défaut de l'AS400. La solution est de décrire les champs du PF qui sont dans cette langue avec le mot clé CCSID(870). Dans le cas présent et puisque tu ne peux pas agir sur les fichiers de la base, AMHA, tu dois passer par un fichier intermédiaire avant de faire les accès. C'est à dire : créer un fichier PF de même format que le fichier d'origine mais où les champs sont décrits avec le bon CCSID, ensuite tu fais un CPYF dans le nouveau fichier (qui contient les zones en CCSID 870) avec l'option *NOCHK et tu fais tes accès à partir de ce fichier. Dans le cas où tu accèdes d'habitude à un LF, tu crées un PF sans un CCSID particulier, tu mets dedans par CPYF les données provenant du LF, tu crées un autre PF avec le CCSID 870 et le tour est joué. Maintenant si tu as d'autres problèmes particuliers....... ? S'il y a d'autres bonnes solutions, je suis preneur aussi. |
|
|
00
|
|
|
#3 |
|
Membre chevronné
![]() ![]() Inscription : mai 2007 Messages : 562 ![]() |
On vient d'essayer et ca a l'air de pas mal marcher à part quelques caracteres qui passent pas mais le probleme dans ce cas peut venir des données de base.
Merci beaucoup pour le coup de main. |
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() ![]() |
Il n'y a pas de quoi et bonne continuation.
|
|
|
00
|
|
|
#5 |
|
Membre chevronné
![]() ![]() Inscription : mai 2007 Messages : 562 ![]() |
Petit ajout des fois que ca serve un jour. Ca marche qu'à moitié avec le code 870. Certains caracteres sont pas récupérés mais avec le 1153, ca marche nickel.
|
|
|
00
|
|
|
#6 |
|
Membre Expert
![]() ![]() |
Bien vu et merci pour l'info.
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com