Bonjour
Je recherche de piste sur une éventuelle limite dans le débit d'écriture (ajouts et modifications) dans les fichiers HyperFile et la disponibilité des index, le tout sur une base C/S.
Contexte : une base HF en client serveur partagé par une dizaine de postes ainsi qu'un exécutable sur le serveur pour synchroniser des données.
Symptôme : des recherches bloquantes n'aboutissent pas. Non pas que l'enregistrement n'existe pas ou qu'il est bloqué... mais semble-t il parce que l'index n'as pas eu le temps de se mettre à jour. On a mis en log les erreurs de retour de nos fonctions Hxxx sans résultat (logs vides malgré l'erreur) et la lecture bloquante ne s'opère pas. Du coup, la procédure déclenche une création d'enregistrement et donc un doublon se génère. C'est ce qu'on doit éviter (ne pas me parler de clé unique, c'est pas le sujet de ce message).
Coté exploitation les postes passent tous pas la même procédure pour l'écriture dans ce fichier et c'est celle qui qui a fait l'objet de nos tests sur le blocage, la position etc...
En revanche, nous avons aussi l'exécutable sur le serveur qui écrit vraiment mais vraiment beaucoup sur ce fichier. Dans ce cas, il récupère des informations dans un thread et met à jour ce fichier (oui, on gère bien le contexte HF...). On a facilement une écriture par seconde dans ce fonctionnement et ce en dehors des accès des 10 autres postes.
Une première utilisation des index fulltext nous avait montré qu'en HF classique, une trop grande fréquence de mise à jour nous cassait régulièrement l'index FTX. Le passage en C/S a résolu ce problème.
Dans le cas présent, nous avons une fréquence d'écriture encore plus élevée.
C'est ce qui me dirige vers la question : y a-t il un débit d'écriture au delà duquel les index ne suivent pas ? Je suis bien conscient de la bizarrerie de la question mais je ne vois pas d'autre raison à l'erreur que l'on rencontre.
Partager