Discussion :

[Loko]

Bonjour

Je suis face à une situation assez étrange. J'ai 2 bases Oracle versions 10 et 9 qui communiquent via db-link. Cela fonctionne bien sauf lorsque certaines données transitent via des objets pl/sql (d'où mon post dans cette section) et contiennent des données.

Voici le détail :

schéma "client" gfc_dev_users, interrogent des données du schéma distant grhgrp. Les données avec accents se trouvent dans la table gsociete.

Cette interrogation de base en sql fonctionne et me retourne des valeurs :

Code :

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

select * from gsociete_test@GRHGRP.xxxx

Maintenant, si je récupère les données via des types table et des fonctions qui retournent des tables, cela fonctionne bien sauf s'il y a des accents dans un champ de la table, j'obtiens alors une erreur ORA-06502.

Voici le code sur le schéma "source" grhgrp dans le package "common" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  TYPE grh_type_societe IS RECORD (
      codesoc    GSOCIETE.GSO_CODSOC%TYPE,
      libelle    GSOCIETE.GSO_LIBLO%TYPE,
      adr1       GSOCIETE.GSO_ADR1%TYPE,
      adr2       GSOCIETE.GSO_ADR2%TYPE,
      cp         GSOCIETE.GSO_CP%TYPE,
      ville      GSOCIETE.GSO_VILLE%TYPE
   );
 
  TYPE grh_type_liste_societes IS TABLE OF grh_type_societe;
 
  Function F_GET_LISTE_SOCIETES_RH_TEST Return Common.grh_type_liste_societes;

La fonction en question est assez basique, utilisation d'un curseur sur la table puis remplissage de l'objet en sortie par boucle sur le curseur.

Code :

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

1
2
   CURSOR c_liste_societes IS SELECT GSO_CODSOC, GSO_LIBLO, GSO_ADR1,GSO_ADR2,GSO_CP,GSO_VILLE FROM GSOCIETE_test
   ORDER BY GSO_LIBLO;

(je peux fournir le détail de ce code s'il le faut, mais ca me semble peu important, vous verrez ci-dessous pourquoi).

Au niveau appel de la fonction dans le schéma client, j'ai ceci :

Code :

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

1
2
3
4
5
6
7
Declare
   t_liste_societes common.grh_type_liste_societes@GRHGRP.xxx := common.grh_type_liste_societes@GRHGRP.xxx ();
 
Begin
 
t_liste_societes := common.f_get_liste_societes_rh_test@GRHGRP.xxx ();
...

et l'erreur se produit sur cette ligne d'appel.

Cela plante donc uniquement s'il y a des accents dans la table gsociete (par exemple sur le libellé de la société) et fonctionne autrement.

Autre indice très important : si je lance le meme code en local sur la base grhgrp cela fonctionne, meme avec des accents !

Je ne sais pas si le db-link est en cause puisqu'un "select" direct fonctionne, c'est juste en pl/sql et utilisation de fonction et type.

J'ai pris soin de déclarer mes objets avec les instructions %Type afin d'assurer le coup ...

Quelqu'un sait-il d'où cela peut venir ?

Merci

[mnitu]

Une piste: les deux bases utilisent des jeux des caractères différents: la base distante utilise un jeu de caractères sur 2 ou plusieurs octets.

[Loko]

bonjour

j'y ai pensé, c'est effectivement le cas : UTF8 coté client et 8859P15 coté service, impossible à changer bien sur

Ce qui m'étonne, c'est que l'interrogation de base en sql fonctionne malgré ces charsets différents, mais pas un appel en PL/SQL. J'ai meme créé une copie de la table source dans la base cliente, puis fait un "insert into .. select * from gsociete_test@grhgrp.xxx" et cela fonctionne, et les accents sont bien là !

J'ai également écrit une fonction de test qui ne me retourne qu'un varchar2 sur le champ contenant les accents, et cela fonctionne. Ce n'est qu'en retournant des objets de type table que cela plante.

Quel est la différence entre les 2, est ce que le moteur d'exécution pourrait interferer au niveau du transcodage ?

[Rei Ichido]

Vous pourriez vous en tirer en modifiant les longueurs des objets, en changeant de VARCHAR2(N BYTE) à VARCHAR2(N CHAR). C'est ce point précis qui fait bugger (le nb de Byte n'étant pas le même pour une même chaîne sur 2 charset différents).

[Loko]

je viens d'essayer, et je confirme !

Merci pour la solution.

Donc les types dynamiques avec "%Type" sont à proscrire dans mon cas, cela apporte de légers inconvénients mais ce n'est pas très grave.

Une petite explication : lorsque je disais que cela fonctionne avec une fonction qui retourne directement le champ, c'est probablement parce que dans ce cas on ne précise (évidemment) pas la longueur du varchar dans la définition de la fonction, et dans ce cas les 2 bases semblent s'en accomoder.

Merci à vous 2.