Discussion :

[GoLDoZ]

salut

voici le topo:

j'ai 2 blocs
dans le trigger KEY-EXEQRY du bloc 1, j'effectue diverses opérations, puis je mets le focus sur le bloc 2 (go_block('bloc 2')

là, c'est le trigger PRE-QUERY du bloc 2 qui prend a main, fait sa cuisine, puis le trigger du bloc 1 continue où il en était

en l'occurence il fait un "execute query;"

j'aimerais connaître la requête qu'il exécute à ce moment-là car ça plante...
(j'ai l'erreur: "Pb sur bloc2.un_item => FRM-40505:ORACLE error:unable to perform query.")

une idée?
merci d'avance


ps: c'est en Forms 6i, à savoir que la même form en 4.5 ne plante pas...

[SheikYerbouti]

Ce message survient souvent lorsqu'il y a inconsistance entre les champs de votre bloc et ceux de la table sous-jacente.
l'erreur fréquente est d'ajouter des champs non basés dans un bloc avec la fonction dupliquer. Le query ne trouve pas la correspondance de colonne de la table...
Vérifiez chaque champ de votre bloc, s'il est basé ou non, son type, sa taille...

[plaineR]

J'ai eu ce style de problème lorsqu'on a migré de forms 4.5 à forms 6. Le problème venait du fait que forms 6 est beaucoup plus rigoureux dans la gestion des datatypes que forms 4.5 (cf. propriétés type de données et longueur maxi, notamment).

[GoLDoZ]

je vais revérifier ce point...

mais comment expliquer que cela fonctionne sous 4.5 et pas sous 6i?
le code n'a pas été modifié entre les 2 mais j'ai déjà remarqué que forms 6 est moins permissif que son prédécesseur...

[GoLDoZ]

J'ai eu ce style de problème lorsqu'on a migré de forms 4.5 à forms 6. Le problème venait du fait que forms 6 est beaucoup plus rigoureux dans la gestion des datatypes que forms 4.5 (cf. propriétés type de données et longueur maxi, notamment).

donc je dois vérifier les propriétés 1 par 1?

[plaineR]

Eh oui, enfin au moins celles des items de ton bloc qui pose problème ! Bon courage !

[GoLDoZ]

rien de louche au niveau des propriétés...

n'y a-t-il pas moyen de récupérer la requête et de l'afficher (avec du pl/sql indépendamment de forms) avant de faire l'execute query?
y a sûrement une fonction qui fait ça...

[Nounoursonne]

Quand tu as cette erreur, si tu fais "SHIFT+F1" tu as le détail de l'erreur ?
ou alors
mis à part tracer ton application, je vois pas trop comment faire

[plaineR]

As-tu essayé :

Code :

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

bloc1.requete := get_block_property ('bloc1', last_query);

[SheikYerbouti]

Si vous "zappez" temporairement le saut dans le boc2 "et votre "petite cuisine", l'execute query est-il correct dans le bloc 1 ?

[GoLDoZ]

@nounoursonne: ça marche pas...

@plaineR: ça ne me ramène rien, et c'est bien mon pb...

@Sheik: je dois laisser le focus sur le block2 sinon il est pas content (Cannot query records here)...

mais j'ai inhibé la cuisine (en fait appel à une fonction dans une librairie qui est censée renseigner les valeurs du block 2 qui constituent la clause where), et ça change rien, vu que dans mon cas, la fonction ne renvoie rien...

je vais pousser la comparaison entre la version 4.5 et la 6...

[SheikYerbouti]

Ne serait-ce point un trigger POST-QUERY qui mettrait le désordre :

[SheikYerbouti]

Vérifiez également que les champs de votre bloc n'ont pas changé de type suite à la migration.

[gaultier]

Bonjour à tous,

Il est possible en Forms de faire afficher un inherit menu (propriété au niveau de la windows mettre à yes ) et de là tu as un menu déroulant HELP et dedans tu as DISPLAY ERROR. Celui ci va te donner l'instruction qu'il a executé et qui pose problème.

A tester

[GoLDoZ]

erf! c bon!

déjà, pour afficher la requête, il suffit de faire "message(:system.last_query);" 8)

en fait, il n'y a aucun changement de type sur les items du bloc2, et c'est là le pb!

un des items est basé sur une colonne date de la vue, celle-ci étant stockée en varchar2(16) ( to_char(DAT_MAJ,'DD/MM/YYYY HH24:MI'))
cet item est de type char également et le format mask est le même
tout cela paraît logique

et bien ça marche en 4.5 mais plus en 6!

en mettant l'item de type date et en supprimant le mask, ça fonctionne...

bref, j'en ai marre de cette appli à la noix!

merci à tous pour votre aide

[SheikYerbouti]

...
un des items est basé sur une colonne date de la vue, celle-ci étant stockée en varchar2(16) ( to_char(DAT_MAJ,'DD/MM/YYYY HH24:MI'))
cet item est de type char également et le format mask est le même
tout cela paraît logique
...

ah bon ? cela vous parait logique d'avoir un item de type CHAR basé sur une colonne de type DATE :

[GoLDoZ]

ah bon ? cela vous parait logique d'avoir un item de type CHAR basé sur une colonne de type DATE :

euh...moi m'être mal exprimé?

la colonne de la vue contient une date mais est de type varchar(16)
et elle est renseignée par to_char(colonne_date_dune_autre_table,'DD/MM/YYYY HH24:MI')

et donc en 4.5 l'item basé était de type char aussi avec le même mask

mais en 6 il faut mettre un type date...

[SheikYerbouti]

ben je ne comprend toujours pas...

quel interêt de mettre un format sur une colonne VARCHAR2 déjà formattée ?

[GoLDoZ]

euh...dsl chuis fatigué aujourd'hui...

c'est l'inverse, l'item était de type date avec un masque, et ça passait
et avec 6, ça passe plus, donc j'ai supprimé le masque et mis le type char

[plaineR]

C'est ce que je t'avais dit : forms6 n'aime pas les conversions implicites (alors que forms 4.5 les supportait). Je m'en suis tapé quelques unes à corriger et j'ai également maudit forms 6i !!!

Par contre une petite précision :
- :system.last_query ramène la dernière requête exécutée concernant la forme;
- alors que get_block_property ('bloc1', last_query) ramène la dernière requête exécutée concernant ton bloc.