Discussion :

[jeremzzz]

Bonjour à tous.

Il y a peu, un de mes programmes a généré une requête SQL de plus de 4000 caractères. Le champ de la base de données stockant cette requête étant en varchar2, impossible de monter plus haut.

A l'heure actuelle mon patron est réticent à passer en long ou clob avant de faire des tests, donc on a dû rester là dessus et bloquer les requêtes de plus de 4000 caractères.

J'ai donc passé tous les champs susceptibles du programme à 4000 caractères dans forms. Ainsi qu'un champ dans une des tables qui était à 1600 et que j'ai monté à 4000.

Cependant voila, au tout début d'une de mes fonctions le programme appelle un curseur sur cette table.

ORA - 6502 est déclenché pile sur l'ouverture du curseur. J'ai donc enlevé ce champ de ma requête, et le problème n'apparait plus ... Une idée du pourquoi ?

Je vous remercie par avance.

EDIT : le client chez qui j'ai ce problème a deux bases. Une base de test et une base de production. L'erreur n'apparait que sur la base de production, qui est rigoureusement identique à la base de test (je viens de vérifier au cas où ...)

[SheikYerbouti]

Difficile de répondre vu le peu d'information. Je me souviens d'avoir eu ce genre de problème car le char set était en UTF8 et les minuscules accentuées, par exemple prenaient plus de 1 caractère dans la chaine.
l'utilisation de CLOB ou NCLOB serait approprié dans votre cas.
C'est facile à tester et à valider.

[jeremzzz]

Je viens de faire quelques recherches par rapport à votre réponse.

La taille du champ ici ne change rien, enfin je pense. Le champ qui pose problème fait 1060 caractères sur la commande que j'utilise pour mes tests.

C'était par rapport à une autre commande que j'ai dû faire ce changement à 4000.

Je passerais en clob ou en long quand j'aurais réussi à motiver mon patron ^^

Vraiment bizarre cette histoire ...

[Garuda]

Je ne sais pas si ca a un rapport mais j'ai souvent des erreurs 6502 dans des forms (6i) que je résous en général en faisant "Compile all" du module.

[jeremzzz]

Ha oui, j'avais oublié de préciser que j'étais sous forms 9i et la base de données en 10g.

J'ai essayé de tout recompiler, et directement chez le client (pour une fois qu'il y a forms sur leur serveur ..) mais sans succès. Toujours cette même erreur.

Ce que je n'explique pas, c'est pourquoi après une modification de la taille du champ dans forms et sur la base de données, l'écran ayant été recompilé, on a une erreur 6502. Surtout que là, les données font 1060 caractères, soit moins que la taille de base avant mes changements ..

[McM]

Faut faire des tests pour être sur de l'endroit où ça plante, rajouter des traces, etc..

[jeremzzz]

Ayant mis un message avant et après mon fetch, je peux certifier que c'est sûr le fetch, puisque le message après ne s'affichait pas.

Cependant la recompilation de l'écran, comme suggéré par Garuda, ne fonctionnait pas. Toutefois, cet écran est lié avec un autre, et tout un tas de package en SQL dynamique où je n'y comprends pas absolument rien (celui qui a fait ce programme à la base était un crac par rapport à moi il faut croire), donc j'ai eu l'idée de tenter de recompiler l'autre.

J'ai aussi fait une recherche des objets invalides de la base de données. Un package appelé par ce programme avait un problème.

Maintenant tout fonctionne.

Donc recompilation des deux écrans ou du package .. un des deux ou les deux étaient la solution. Merci à vous de m'avoir orienté vers la solution.