[Forms 10g] Problème lors de l'exécution d'un trigger

Bonjour,

Après migration en 10g, la requête ci-dessous

Code:

---

1 2 3 4 5 6

select c_etab,c_guichet,c_compte,c_cle_compte,l_dom_bq into :decomptes.c_etab,:decomptes.c_guichet, :decomptes.c_compte,:decomptes.c_cle,:decomptes.l_etab from solde where c_nls=:admin.c_nls;

---

où les 5 variables :decomptes.c_etab, :decomptes.c_guichet, ... représentent des champs basés d'un bloc de données basé

remonte le message

Citation:

---

FRM-40735 : Le déclencheur ON-ERROR a détecté une exception ORA-06502 non traitée

---

Celle-ci fonctionnait parfaitement sous Forms 4.5

Y a-t-il une contre-indication sous Forms 10g de remplir des blocs basés à partir d'une requête SQL ?? ...

Merci pour votre aide.

Si vous avez besoin davantage de précision, n'hésitez pas.

Bonne journée.

Fabien DUBOIS

Il s'agit d'un dépassement de capacité : vérifiez que chaque variable de la clause INTO est du type ET de d'une profondeur suffisante pour la colonne correspondante du SELECT.

C'est en parfaite adéquation tant au niveau du type que de la profondeur de champ.

Ce qui est curieux, c'est que le message apparaît 5 fois à l'écran, apparemment pour chaque valorisation dans le INTO

Et pour la variable suivante ?

Code:

---

...c_nls=:admin.c_nls

---

D'autre part, si vous exécutez cette requête avec les valeurs des variables substituées sous SQLPlus, cela produit-il le même message d'erreur ?

Aucun pb avec le type et la profondeur de la variable c_nls.

Sous SQLPlus, la requête s'exécute bien.

Par ailleurs, j'ai remarqué qu'en passant la propriété 'Element de bloc de données' de 'yes' à 'no' pour chacun des 5 éléments du bloc Decompte entrant dans la clause INTO, le message n'apparaîssait plus.

Avez-vous une explication ???

Ma solution n'est de toute façonpas pérenne puisque à l'ouverture de mon écran ces 5 champs sont remplis lors de l'exéction d'un ordre EXECUTE_QUERY sur la table DECOMPTE.

J'espère que ça va vous mettre sur la voix.

Merci

Pour moi il y a une contradiction dans ce que vous dîtes :

Citation:

---

Envoyé par duboisfa

où les 5 variables :decomptes.c_etab, :decomptes.c_guichet, ... représentent des champs basés d'un bloc de données basé

---

et

Citation:

---

Envoyé par duboisfa

j'ai remarqué qu'en passant la propriété 'Element de bloc de données' de 'yes' à 'no' pour chacun des 5 éléments du bloc Decompte entrant dans la clause INTO, le message n'apparaîssait plus

---

Vous comprenez que cette propriété détermine l'origine des valeurs de ces items.
Si vous positionnez à 'Non' et que vous n'affectez pas une valeur explicitement alors, lors de l'exécution de votre requête, les variables du bloc doivent être à NULL.
Pour vous en convaincre, afficher le contenu de vos variables de blocs avant l'exécution de la requête ou utilisez le déboggueur.

Parfaitement d'accord avec ton explication, c'était juste pour faire un test.

Ceci dit, je viens de remarquer quelque chose de plus étrange encore. En exécutant mon trigger sous Windows à partir de Forms Builder 10g, aucun message d'erreur n'apparaît. Par contre, à partir de mon serveur d'applis Oracle Forms&Reports Services 10g sous Linux, le message d'erreur s'affiche.

Une idée là-dessus ??

Merci.

Vous n'avez pas de piste ??

Votre dernier post me rend perplexe.
Mes connaissances ne sont pas assez pointues pour vous répondre.
Je ne saurais que trop vous conseiller que de fouiller sur Metalink ou sur internet...

en Forms 9i , il faut utiliser :name_in , copy ...

http://sheikyerbouti.developpez.com/...0g/?page=Chap7

allez, un p'tit effort ....


CDLT.

Pas du tout, tu peux continuer à utiliser les :decompte.item := en forms 9 et 10.. heureusement sinon je te dis pas l'enfer des migrations.

Bref, duboisfa on va reprendre du début :
Donne le nom du trigger et le code complet.