Discussion :

[m4k-Hurrican]

Bonjour,

Me voilà bien embêté, et je me demande si je ne vais pas devoir contacter IBM, pour un souci qui ne devrait pas en être un.
Un programme en .net qui fonctionnait jusqu'à présent parfaitement, rencontre désormais une erreur bloquante.

Nous effectuons des Insert dans un fichier, comportant 15 champs (dont les 2/3 nullable), via une mise à jour de masse (addBatch, et ExecuteNonQuery) pour ne pas passer un après-midi en mise à jour.

Le fichier est relativement récent, définit en DDL, avec un chemin d'accès plus qu'assez grand (ACCPTHSIZ définit à *MAX1TB, SIZE à *NOMAX).
Mais depuis aujourd'hui, à l'exécution, on obtient un SQL0904 : la limite des ressources a été dépassée
Qui se traduit dans le job QZDASOINIT correspondant, par un CPF4287 : Limite mémoire atteinte pour membre xxx
Nous sommes à 50% de capacité sur l'ASP, et le fichier, donc, est très loin d'approcher la limite de taille fixée.
J'ai essayé en entrant un seul enregistrement au lieu des quelques centaines normalement, et j'obtiens le même message.
Les 3 autres fichiers, pourtant plus gros, qui sont mis à jour dans la même routine, ne posent aucun problème, eux.

Je soupçonne donc un bug dans le pilote.
Quelqu'un aurait une idée lumineuse pour nous sortir de là sans qu'on doivent attendre des mois qu'IBM fixe le problème ?

[m4k-Hurrican]

Après étude de l'historique, j'ai trouvé ce qui provoque le blocage, et c'est du à une mauvaise prise en charge du mode étendu par le pilote ODBC.
3 champs ont évolué, et sont passés en UTF-8 pour l'encodage. Mais dans le fichier on a aussi des champs en CCSID 1147.
Si on met tout les champs dans le même encodage, çà passe.

C'est étrange, car pour d'autres fichiers, où on utilise les mêmes différences (1147 pour les anciens champs issus des écrans verts, et UTF-8 pour les nouveaux champs gérés par l'interface Web ou en .net), on a pas ce souci.
Mais avec ce fichier, on plantait à chaque fois.
Je contacte quand même IBM, car pour nous c'est embêtant d'avoir des URL encodées en 1147, même si dans ce cas précis, c'est moins grave (URL facultatives d'informations).

Je passe à résolu, mais je reviendrai surement si IBM me donne plus d'infos, ou sort un correctif.