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

Forms Oracle Discussion :

[12c] Problème exécution de requête dans un bloc esclave


Sujet :

Forms Oracle

  1. #1
    Candidat au Club
    Inscrit en
    Novembre 2010
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 3
    Points : 2
    Points
    2
    Par défaut [12c] Problème exécution de requête dans un bloc esclave
    Bonjour à tous,

    Voici le problème que je rencontre dans un écran avec 2 blocs liés par une relation, la gestion des données du premier bloc étant faites dans un écran dédié et l'écran courant permettant la gestion des données du second bloc associées à celles du premier bloc.

    Les utilisateurs ont utilisé la valeur "#" comme code des données maîtres et lorsque la relation déclenche l'exécution de la requête du second bloc, une erreur FRM-40505 s'affiche. L'appui sur Shift+F1 affiche la requête en erreur telle que suit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT CPAC.COD_TYP_PER,CPAC.COD_TYP_ASS,TA.LIB_TYP_ASS,CC.lib_cou,CPAC.COD_COU,CC.COD_COU_POLICE 
    FROM CALENDRIERS_PER_ASS_COULEUR CPAC, TYPES_ASSOCIATION TA, CALENDRIERS_COULEURS CC 
    WHERE CPAC.cod_typ_ass = TA.cod_typ_ass and CPAC.cod_cou = CC.cod_cou and (CPAC.COD_TYP_PER ) order by CPAC.cod_typ_per, CPAC.cod_typ_ass
    Si on essaye d'afficher les donnée pour les données maîtres du code "$", tout se passe bien. La même requête avec le code correspondant est la suivante (affichée dans un champ texte par LAST_QUERY du bloc) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT CPAC.COD_TYP_PER,CPAC.COD_TYP_ASS,TA.LIB_TYP_ASS,CC.lib_cou,CPAC.COD_COU,CC.COD_COU_POLICE 
    FROM CALENDRIERS_PER_ASS_COULEUR CPAC, TYPES_ASSOCIATION TA, CALENDRIERS_COULEURS CC 
    WHERE CPAC.cod_typ_ass = TA.cod_typ_ass and CPAC.cod_cou = CC.cod_cou and (CPAC.COD_TYP_PER='$') order by CPAC.cod_typ_per, CPAC.cod_typ_ass
    Auriez-vous une idée pour contourner le problème sachant que je ne peux pas modifier le code "#" utilisé depuis bien trop longtemps à bien trop d'endroits.
    Existerait-il un moyen de d'intercepter la requête avant son exécution pour un modifier le contenu (sachant que modifier le contenu du champ (en ajoutant un caractère d'échappement par exemple) ne fonctionne pas et provoque d'autres erreurs)...
    Ou bien utiliser une instruction du type Set quelquechose valeur (comme lorsque l'on fait Set Escape "\" par exemple -mais pas dans ce cas là-) qui permettrait à Forms d'interpréter le caractère # différemment ???

    Exit les réponses du genre : Contrôle tes champs non basés et autres joyeusetés annexes... Le problème vient bien de la donnée.

    Bien à vous tous en espérant lire une solution à ce casse-tête

    Cordialement

  2. #2
    McM
    McM est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur Oracle
    Inscrit en
    Juillet 2003
    Messages
    4 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Oracle

    Informations forums :
    Inscription : Juillet 2003
    Messages : 4 580
    Points : 7 740
    Points
    7 740
    Billets dans le blog
    4
    Par défaut
    C'est marrant, je viens de faire un mail vendredi dernier à mon service de dev pour les informer de ce genre de problème (sur les jointures auto entre bloc maitre-détail) : Attention une jointure auto est une jointure au niveau des champs Forms (c'est un simulacre de enter-query, renseigner les champs avec les valeurs du parent, execute_query)
    Si un des champs contient _ ou % => condition where LIKE
    Si un des champ est NULL => pas rajouté
    Si un des champs contient < ou > => condition where < ou >
    J'avais pas testé le # => tu dis plantage

    Le mieux est de mettre la jointure dans le WHERE du bloc détail.
    Ensuite soit tu gardes ta jointure auto (s'il y a plusieurs colonnes) pour n'en garder qu'une qui ne puisse pas planter (exemple un number), afin de laisser Forms gérer le Requery automatique, et l'alimentation
    Soit tu le gères à la main : Trigger when-new-record-instance sur le maitre qui fait un
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    go_block détail; execute_query; go_block maitre; -- voir s'il faut mémoriser la position du curseur dans le maitre pour y retourner
    More Code : More Bugs. Less Code : Less Bugs
    Mon Blog PL/Sql : Fichier Zip / Image BMP / Lire sqliteDB / QRCode et Images PNG ou BMP

  3. #3
    Candidat au Club
    Inscrit en
    Novembre 2010
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 3
    Points : 2
    Points
    2
    Par défaut Dernier acte
    Bonjour,

    Merci McM pour ta réponse qui m'a permis d'orienter mes investigations dans différentes directions. J'ai donc opté pour la solution suivante qui marche pas trop pal pour l'instant :

    Sachant que mon bloc maître est en interrogation et consultation seules, et que mon 2ème bloc permet le DML, j'ai créé une relation entre mes deux blocs tout ce qu'il y a de plus classique et ensuite j'ai supprimé la valeur de la propriété "Copier valeur de l'élément" mise par défaut lors de la création de la relation.
    Dans la procédure Query_Master_Details, avant de me déplacer vers le bloc détail et l'"execute_query", je modifie la propriété "DEFAULT_WHERE" du bloc détail en reprenant les conditions de jointures existantes (champs de plusieurs tables affichés dans ce bloc) et j'y concatène la condition de jointure avec la valeur du champ en clé étrangère du bloc maître (ce qui aurait dû être dans le "Copier valeur de l'élément").
    Pour éviter (presque) tout risque d'erreurs, j'empêche l'interrogation sur ce second bloc (qui me fait perdre la valeur du lien de clé étrangère), sachant que pour l'instant, le nombre d'enregistrements détails n'excède pas une page et ne l'excédera guère plus, et dans le cas d'ajout ou modification d'enregistrement je viens renseigner le code de ma clé étrangère dans le trigger WHEN-VALIDATE-RECORD du bloc détail, si celui-ci ne l'est pas et qu'il le nécessite.

    J'espère avoir été suffisamment clair.

    Bien à vous tous.

  4. #4
    Candidat au Club
    Inscrit en
    Novembre 2010
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    J'avais oublié...
    Pour info : Ce bug ("#" utilisé en interrogation dans un champ et qui génère une erreur) est référencé chez Oracle (non résolu pour l'instant mais peut-être l'objet d'un prochain patch)

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

Discussions similaires

  1. [AC-2010] Comment désactiver l'exécution des requêtes dans une macro.
    Par JOSIE1491 dans le forum Access
    Réponses: 7
    Dernier message: 27/06/2018, 14h11
  2. Problème exécution de requête Android -> PHP -> MySQL
    Par BibiDev11 dans le forum Android
    Réponses: 5
    Dernier message: 10/01/2014, 15h11
  3. Exécuter une requête dans un formulaire?..
    Par NOVICE18 dans le forum Modélisation
    Réponses: 2
    Dernier message: 13/02/2013, 18h00
  4. [2.x] Exécution plusieurs requêtes dans la même page
    Par fattouch_squall dans le forum Symfony
    Réponses: 1
    Dernier message: 01/12/2011, 11h14
  5. Problème avec une requête dans SQL-Server
    Par krolis dans le forum Développement
    Réponses: 6
    Dernier message: 09/01/2011, 21h53

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