Bonjour,

J'ai un curseur sur une table de la base, qui retourne 210 enregistrements.
Je dois écrire un fichier XML à partir de ces enregistrements : pour chacun d'eux, les valeurs à écrire dans le XML sont tirées de la base, et une dernière doit être lue dans un fichier texte, par ailleurs parfaitement accessible au SGBD (directory déclaré avec les droits kivonbien).
A chaque passe du curseur, ce fichier texte est ouvert, lu, et refermé.
Le seul qui reste constamment ouvert est donc le fichier XML en cours d'écriture.

Ce qu'il se passe : systématiquement à partir du seizième élément et au-delà, le SGBDR refuse obstinément d'ouvrir les fichiers textes...
Obstinément signifie : le 16° fichier existe, comme les 15 précédents (qui ont tous été lus sans aucun problème) et absolument tous les suivants, il est non vide, il est situé au même endroit, dispose des même droits rw-rw-rw et appartient au même propriétaire.
J'ai rusé pour limiter les enregistrements renvoyés par le curseur au 15 et 16° de la liste initiale: ouverture sans aucun souci du fichier 16 qui avait été refusé à la passe précédente, donc, il n'y a pas de problème inhérent au fichier lui-même.
J'ai re-rusé pour renvoyer une autre liste que la liste initiale: "ouverture impossible" à partir systématiquement du 16° fichier ouvert. Quels que soient les enregistrements renvoyés par le curseur, le SGBD refuse toute ouverture à partir du 16° fichier, et tous les autres.
J'ai tenté un FFLUSH du fichier XML en écriture à chaque passe. Aucun effet.

Y a-t-il une limite par défaut au nombre de fichier ouverts ?
Je rappelle que ce ne sont pas des ouvertures concurrentes puisque chaque fichier est supposé être ouvert, lu, et refermé avant de passer au suivant.

Merci pour votre aide.