[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:

---

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:

---

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

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:

---

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

---

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.

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)