2016-05-10 1 views
1

Je travaille actuellement sur un projet dans mon organisation où nous migrons Informatica Powercenter dans notre application de la version 8.1 à la version 9.1.Traitement incorrect des caractères spéciaux dans Informatica Powercenter 9.1

Informatica PC charge des données à partir de fichiers de données mais ne peut pas conserver certains caractères spéciaux présents dans quelques fichiers dat d'entrée.

Les données ont été chargées correctement dans v8.1.

ai essayé de modifier les paramètres de caractères ne en Informatica comme ci-dessous -

CodePage movement = Unicode 
NLS_LANG = AMERICAN_AMERICA.UTF8 to ENGLISH_UNITEDKINGDOM.UTF8 
"DataMovementMode" = Unicode 

Après avoir effectué les réglages ci-dessus, je reçois l'erreur ci-dessous dans le dans le journal Informatica:

READER_1_2_1> FR_3015 Warning! Row [2258], field [exDestination]: Data [TO] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2265], field [exDestination]: Data [IOMR] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2265], field [parentOID]: Data [O-MS1109ZTRD00:esm4:iomr-2_20040510_0_0] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2268], field [exDestination]: Data [IOMR] was truncated. 

Le caractère spécial qui sont envoyé dans les données sont et ne pas être traitées correctement -

Ø 
Ù 
Ɨ 
¿ 
Á 

Quelqu'un peut-il guider s'il vous plaît comment résoudre ce problème? Quoi d'autre est nécessaire à Informatica fin d'être changé. Des paramètres de session doivent-ils être définis dans la base de données?

Merci

Yavnica

+0

Définir la source et cible codepages UTF8. – Samik

+0

Nous avons la source en fichier plat délimité par | caractère et la base de données cible est oracle 10g. J'ai changé les paramètres comme ci-dessous, le mode de déplacement de données de service d'Integartion à Unicode, la page de code source de dossier plat au codage UTF-8 d'unicode, NLS_LANG du client de powercenter à ENGLISH_UNITED \ KINGDOM.AL32UTF8. Cela ne fonctionne toujours pas –

+0

Vous devez également modifier la page de codes dans les propriétés du fichier source en UTF8. UTF8 doit également être configuré dans l'objet de connexion pour Oracle. – Samik

Répondre

0

pour fonctionner en mode Unicode pour obtenir les meilleurs résultats en dehors de la configuration ODBC et les connexions relationnelles pour utiliser Unicode

Pour votre information

pouvez également définir votre service d'intégration (IS) a Unicode - IS autorise 2 octets pour chaque caractère et utilise un octet supplémentaire pour chaque caractère non-ascii (tels que les caractères japonais/chinois)

b) ASCII-IS contient toutes les données dans un seul octet

Assurez-vous que la taille de la variable est suffisante pour contenir les données. Quelques fois les avertissements mentionnés seront reçus lorsque la taille est petite pour contenir les données entrantes

Merci et salutations

Raj

0

Je posté dans un autre thread sur les caractères spéciaux. S'il vous plaît vérifier si cela est de toute aide.

  1. Commencez par la source dans le concepteur. Êtes-vous en mesure de voir les données correctement dans l'aperçu du qualificatif source? Si ce n'est pas le cas, vous pouvez définir le codage de la définition de source ff sur UTF-8.
  2. Le service d'intégration doit s'exécuter en mode Unicode et non en mode ASCII. Vous pouvez vérifier cela à partir des propriétés du service d'intégration dans la console d'administration. La cible doit être un codage UTF-8.
  3. Vérifiez la connexion relationnelle (si la cible est une base de données) le codage dans le gestionnaire de workflow pour vous assurer qu'il est UTF-8
  4. Si le problème persiste, écrire la sortie vers un utf-8 flatfile et vérifier si les données sont en cours de chargement correctement. Si oui, le problème est d'écrire dans la base de données.
  5. Vérifiez les paramètres de base de données comme NLS_LANG, NLS_CHARACTERSET (pour Oracle), etc.

Merci