Discussion :

[duboisfa]

Bonjour,

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

Code :

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

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

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

[Magnus]

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.

[duboisfa]

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

[Magnus]

Et pour la variable suivante ?

Code :

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

...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 ?

[duboisfa]

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

[Magnus]

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

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

et

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.

[duboisfa]

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.

[duboisfa]

Vous n'avez pas de piste ??

[Magnus]

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...

[taska]

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

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

allez, un p'tit effort ....


CDLT.

[McM]

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.