Version imprimable
Je comprends ton désarroi. Microsoft ne va pas se mouiller et pcsoft insistera pour que tu passes en CS.
Dans tous les cas, il faudra que tu passes en CS (ou sur une autre base de données). HF classic n'est pas fait pour ce que tu fais. J'ai le même pb au boulot. De temps en temps, on a des applis qui bloquent ou des index corrompus à cause des accès concurrents...
Salut,
Oui je sais, nous devrons y passer tôt au tard au C/S.
En attendant, pendant plus de 10 ans notre base à fonctionné correctement avec un environnement serveur 2003 et les mêmes postes clients qu'aujourd'hui, donc pour moi HF Classic est tout à fait suffisant et solide. Au maximum nous avons 15 postes susceptibles d'accéder aux fichiers en même temps, ce n'est donc pas "la mer à boire" pour HF Classic...
Non, je persiste à croire qu'on peut très bien rester en Classic dans notre cas même si je sais que PCSoft ne m'aidera pas tant que nous ne serons pas passé en C/S....
Si au moins d'autres développeurs pouvaient témoigner (a part toi et serendib) , sur ce forum ou sur d'autres, mais manifestement personne ne se mouille....
Dommage.
Beaucoup de développeurs ici mais 2 écoles (attention, je schématise et fais des gros traits) :
- Les débutants et ceux qui y sont "contraints" sont en HF classic. Au "mieux" en CS. Ils utilisent les fonctions Hxxx.
- Les "experts" refusent HF et travaillent sur mysql, postgrsql, ... ne veulent pas entendre parler des fonctions Hxxx et n'utilisent que SQL.
Dans mon boulot, j'ai du HF classic et un serveur HFCS. On a de temps en temps besoin de réindexer (classic) mais c'est qd même rare, même si certains fichiers sont assez lourds...
[EDIT] : Dans les 2 cas, je fais des requêtes et j'utilise les fonctions Hxxx, suivant les besoins.
On peut être "expert" dans le développement d'applis de gestion ou autres type de dévs et selon le besoin du moment choisir tel ou tel type de base de donnée ! Pour notre part, nous utilisons depuis très longtemps le HF pour nos besoin de gestion et nous en sommes globalement satisfaits mais pour autant nous faisons aussi du SQL avec d'autres types de base MySQL ou SQLite par exemple (sur Android + Java)
Le fait est que les développeurs Windev ayant choisi HF Classic comme nous pour leurs besoins ou ceux de leurs clients, doivent être nombreux et ont sans doute un retour d'expérience à faire partager !?
Cependant si on s'en tient aux réponses reçues, soit quasiment personne n'utilise HF Classic, soit (et c'est le plus probable) ils ont quelques soucis parfois (comme toi) de corruption d'index, mais font avec et cherchent des contournements plutôt qu'essayer de comprendre ce qui est à l'origine de leur problème!
Personnellement et afin d'assurer la pérennité de mes choix technologiques, j'aime bien comprendre dans le détail ces technos et essayer le plus possible de comprendre ce qui est à l'origine du problème.
Je suis donc sur une piste mais pour la valider, j'ai besoin de recouper avec d'autres cas récents dans le même environnement, sinon je devrais en conclure peut être à tord, que je ne suis pas sur la bonne piste...
Jusqu'à présent, je n'ai jamais eu de souci majeur sur HF. Plutôt des choses enquiquinantes (gestion des espaces car mix entre wd55 et classic).
Je pense que si tu fais des choses "simples" HF fonctionne très bien.
Si tu te retrouves avec une base de 300 tables avec des requêtes multi-jointures et beaucoup d'utilisateurs, HF classic va s'avérer un mauvais choix.
En CS, je n'ai pas eu l'occasion d'avoir une "grosse" base.
Essaye de regarder du côté du sondage (sur ce forum) concernant les types de BDD utilisées avec windev.
[EDIT] Pour ton problème. As-tu fait des recherches avec ton patch windows avec foxpro et isam ? Foxpro est (était ?) "la" base de données microsoft en isam (format de fichiers hérité de dbase).
Merci de ton aide et de tes conseils.
Je pense aussi que HF fonctionne très bien même pour des choses plus compliquées d'ailleurs...et c'est bien pour cela que j'insiste à trouver la raison de ces soudaines erreurs que je n'ai quasiment jamais eu en + de 15 ans de dév avec Windev!!
Je vais jeter un oeil à cet espace "sondage" mais je crains fort que cela ne m'aide pas à résoudre mon PB actuel.
Avec toutes mes recherches, je commence à "maîtriser" le protocole SMB2 et la gestion du cache côté client mais j'ai quand même du mal à croire qu'il puisse s'agir d'un dysfonctionnement de ce côté là, même si Microsoft à déjà publié des hotfix sur ce sujet et conseille de modifier cette gestion (clés de registre) si on soupçonne que cela puisse engendrer des problèmes de corruption de données...
Difficile donc d'aller plus loin dans mes recherches tant que je ne saurais pas si je suis seul dans ce cas en 2013 (les autres cas trouvés datant de 2 ou 3 ans avant les hotfix de Microsoft)
Désolé pour la réponse tardive, mais j'étais un peu "out".
Moi, les pb SMB2 ne me surprendraient pas outre mesure. MS fait sa soupe de son côté et se fiche un peu des conséquences sur les softs déjà en place...
Tiens nous au jus sur la résolution de ton problème.
Bonjour et merci de te préoccuper de mon souci, ce qui n'est malheureusement pas le cas de grand monde...
Pour info notre souci de corruption d'index ne s'est pas encore reproduit depuis le 15 mars dernier et ce vendredi nous migrons les fichiers HF5 en HF7 ainsi que nos 40 applications internes les utilisant (toutes ont été recompilées et surtout testées!)
Côté recherches, je n'ai pas avancé car sans aide ou autres témoignages je ne peux incriminer avec certitude un dysfonctionnement côté SMB!
Merci encore.
Si tu migres en HF7, tu ne devrais à priori ne plus avoir ton pb.
Juste un conseil (que je pense inutile) : sauvegarde tout !!!
- tes anciens exécutables sur les postes et
- ta bdd avant la migration. De mémoire, wdconvert te demande si tu veux sauvegarder.
Tu as viré les espaces ou tu restes en "gestion espaces compatible 55" ?
Dans le premier cas, tu as fait un grand pas vers CS...
J'espère effectivement qu'en Classic le problème sera résolu même si je n'en suis pas sûr du tout!
Si cela vient bien de SMB, tant qu'on ne sera pas passés en CS on ne sera pas à l'abri.
Pour les espaces, nous les avons gardés car cela représente trop de modifications dans tous nos projets et trop de risques de régression.
Par contre, après cette migration nous attaquerons le passage progressif en CS fichier par fichier et à ce moment là, nous modifierons le code pour ne plus gérer ces espaces lors des recherches et des filtres.
Merci.
Désolé de ne pas t'avoir répondu plus tôt mais j'ai été un peu bousculé... Comment c'est passée tapremière bascule ? Cela fonctionne correctement ? Prêt pour la grande migration ?