IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PL/SQL Oracle Discussion :

Problème d'utilisation accents,db-link et pl/sql (ORA-06502)


Sujet :

PL/SQL Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    344
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : Juillet 2004
    Messages : 344
    Par défaut Problème d'utilisation accents,db-link et pl/sql (ORA-06502)
    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

  2. #2
    Expert confirmé Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Par défaut
    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.

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    344
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : Juillet 2004
    Messages : 344
    Par défaut
    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 ?

  4. #4
    Membre Expert
    Inscrit en
    Août 2009
    Messages
    1 073
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 1 073
    Par défaut
    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).

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    344
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : Juillet 2004
    Messages : 344
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Problème d'utilisation de Mysql avec dev-c++
    Par Watchi dans le forum Dev-C++
    Réponses: 10
    Dernier message: 06/08/2004, 14h35
  2. [cvs] problèmes d'utilisation
    Par gromite dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 29/06/2004, 17h41
  3. Problème: Requête utilisant NOT IN
    Par fages dans le forum Langage SQL
    Réponses: 4
    Dernier message: 04/05/2004, 10h18
  4. [JDBC] Problème avec les accents
    Par seawolfm dans le forum Administration
    Réponses: 2
    Dernier message: 29/01/2004, 14h56
  5. problème d'utilisation avec turbo pascal 7.0
    Par le 27 dans le forum Turbo Pascal
    Réponses: 4
    Dernier message: 03/12/2003, 10h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo