|
| Hyper File en local, réindexation et HExécuteRequête |
| Started by Patrick Marty, Jul., 29 2021 10:56 AM - 6 replies |
| |
| | | |
|
| |
Posted on July, 29 2021 - 10:56 AM |
Bonjour,
J'utilise Hyper File en local et les fichiers de données sont lus et modifiés depuis plusieurs instances de l'application (service, application avec interface et application lancée en tâche de fond).
Les problèmes d'index et de mémos corrompus sont fréquents. Je constate que lorsque je réindexe un fichier corrompu dans une instance de l'application, les autres instances une fois la réindexation terminée ne peuvent plus exécuter les requêtes basées sur ce fichier.
En bref :
Instance 1 lancée, exécute une requête. OK.
Instance 2 lancée, réindexe le fichier. OK.
Instance 1 réexecute la requête -> erreur d’index corrompu, réindexez.
Si dans cette Instance 1, il y a réindexation, c’est alors dans les autres instances que les requêtes sur ce fichier ne pourront plus s’exécuter.
L’accès au fichier lui-même ne génère pas d’erreur, c’est :
HExécuteRequête(REQ_HomelandLog)
nNBRecord = HNbEnr(REQ_HomelandLog)
qui plante sur HNbEnr
J’ai cherché sans succès comment contourner ce problème. Pour l’instant, quand il y a réindexation, je quitte et relance tout le petit monde. C’est lourd, pas optimisé et pas ergonomique.
NB : Windev 25
Si vous avez une idée, je vous en remercie d'avance,
Patrick Marty |
| |
| |
| | | |
|
| | |
| |
Registered member
1,935 messages
Popularité : +53 (65 votes) |
|
Posted on July, 29 2021 - 5:25 PM |
Bonjour,
Je crois que la réponse est dans la question : "J'utilise Hyper File en local" 
--
Bon dev,
Jean-Pierre |
| |
| |
| | | |
|
| | |
| |
Registered member
227 messages
Popularité : +18 (20 votes) |
|
Posted on July, 29 2021 - 5:31 PM |
Bonjour,
hyperfile local bonjour les accès concurrentiels
hyperfile local + SQL pas utras rapide enfin chez moi le sql est moins rapide quand j'ai pas un HFCS en place
Vos index sont corrompus sur update ou delete ?
Actuellement il m'arrive d'avoir encore des base en local et je ne fait que des SELECT en requete le reste en hmodifie() et hsupprime() car je peux gérer des blocages et mettre en place des files d'attentes jusqu'à ce que l'enregistrement soit débloqué (si il est débloqué un jour)
Vous pouvez faire un service qui est seul responsable de l'accès au fichier mais ça reviens a inventé la roue faite par pc soft
Y a t’il une raison pour lequel vous n'utiliser pas HFCS ?
Je crois qu'il existe une option à la connexion pour dire de prendre plus de temps à l'écriture et évité les erreurs d'index.
HSécurité(2) |
| |
| |
| | | |
|
| | |
| |
Posted on July, 29 2021 - 6:10 PM |
Bonjour,
merci pour votre réponse.
> hyperfile local bonjour les accès concurrentiels
Oui, effectivement, il faut blinder avec de la section critique et du mutex. Et l’identifiant unique numérique, c’est aussi lourd à gérer. Je précise, les fichiers locaux ne sont pas en partage de fichiers comme on faisait en 2005 (et je n’avais pas de soucis, sauf de lenteur).
Y a t’il une raison pour lequel vous n'utiliser pas HFCS ?
Ce sont des données locales au poste, des logs d’activités réseau principalement. L’application se connecte aussi sur un serveur HFCS, mais pour enregistrer et chercher d’autres types de données.
En local, il y a majoritairement du HAjoute et HModifie. Puis des recherches avec des requêtes.
Sur le serveur HFCS, il y a déjà 17 millions d’enregistrements à maintenir et mettre à jour avec une augmentation de 500 000 enregistrements par mois et qui sont quotidiennement beaucoup consultés par les postes clients. Il n’est pas raisonnable de remonter en plus les logs et informations locales de chaque client, surtout que le serveur est hébergé et les clients s’y connectent par Internet (France, Espagne, Canada).
Ce que je cherche c’est à garder ces fichiers locaux le plus optimisé possible, parce que les informations enregistrées sont aussi utilisées pour des recherches, donc je réindexe fréquemment. Problème, les requêtes des instances déjà lancées ne s’exécutent plus.
Ces données locales sont consultées (listing, éditeur de recherche, statistiques), et si derrière le service réindexe l’un des fichiers impliqués, pour l’instant pas d’autre choix que de quitter l’application et la relancer. Je cherche à exécuter mes requêtes sans avoir à relancer l’application. |
| |
| |
| | | |
|
| | |
| |
Posted on August, 23 2021 - 12:38 PM |
Bonjour,
je repose ma question, malgré mes tests et recherches, aucun moyen de réindexer un fichier HF local et executer une requête dans une instance déjà lancée.
Merci |
| |
| |
| | | |
|
| | |
| |
Registered member
1,935 messages
Popularité : +53 (65 votes) |
|
Posted on August, 24 2021 - 10:25 AM |
Bonjour,
Je reformule la question posée par Gurdarr :
Pourquoi ne pas installer un serveur HFSQL en local ?
Bon, il faut modifier l'application mais, avec la lecture d'un paramètre sur le poste, on peut même proposer les 2 solutions au choix.
Un petit investissement au départ mais que de difficultés aplanies après !
--
Bon dev,
Jean-Pierre |
| |
| |
| | | |
|
| | |
| |
Posted on August, 25 2021 - 12:26 PM |
Bonjour,
le logiciel est utilisé sur des serveurs et des postes clients. Déployer HFSQL Serveur sur des postes sur lesquels je n'ai pas la main et des postes qui peuvent avoir comme processeur un i3 avec seulement 4G de RAM, c'est lourd. HFSQL Serveur a aussi ses défauts et nécessite en terme de maintenance plus d'attention qu'un fichier de données local.
Utiliser HFSQL Serveur en local est une solution. Mais je suis pour l'instant à la recherche de quelque chose de plus léger, d'une solution pour un problème concret de réindexation qui bloque l'exécution de requêtes dans des instances tierces déjà lancée. Quelque chose de plus léger.
Merci |
| |
| |
| | | |
|
| | | | |
| | |
|