hf classic versus hf client serveur

[tim501]

Bonjour,

J'ai une appli en clientèle qui a tourné comme une horloge en version 5.5
Je l'ai migrée en 16. Après correction des inévitables petits bug dus à la migration je me retrouve avec des problèmes de pertes de données qui se corrigent après réindexation.

Question posée à pcsoft qui me conseille de basculer en client/serveur.

Est-ce quelque quelqi'un à eu ce genre d'expérience ?
D'une manière générale est-il recommandé d'utiliser hfcs plutôt que hf classic quand on est en réseau ?

Merci d'avance pur vos réponses.

Cordialement.

[Yusep]

Bonsoir
Je prefere refaire l'appli en WD15 plutot qu'importer avec WD7.5.
Ensuite je copie les fonctions personnelles.
Sur une appli 5.5 j'ai eu un probleme similaire, seulement sur un poste.
Je l'ai resolu en reindexant avec WDOutil.
Voir les droits sur les dossiers...

[frenchsting]

Si tu migres un appli de 5.5 vers 7.5 ou plus, je te conseille de reprendre toutes les instructions estampillées _55 et de les mettre à la nouvelle syntaxe.

De plus, le comportement de certaines instructions a changé... Bref, il y a du pain sur la planche...

Le passage en CS se justifie surtout si tu as du multiposte simultané...

[tim501]

L'application est déjà migrée et est en place et j'ai enlevé tout ce qui pouvait rappeler la 5.5. L'application est en 16 et tourne sur un réseau d'une dizaine de postes comme la précédente version la nouveauté étant que la version 16 semble plus sensible aux aléas du réseau ce que je comprendrais assez facilement vu le travail fait par pcsoft sur les index le nouveau système par statistique se payant par une fragilité accrue me semble-t-il.

Ce que j'aimerai avoir comme confirmation c'est ceci : la solution au problème serait de basculer en C/S. Donc peut-on conclure qu'une appli en réseau tourne mieux en C/S, autrement dit qu'il serait déconseillé de la faire tourner en hf classic.

C'est ce j'aimerai avoir comme confirmation le top étant un retour d'expérience.

Merci d'avance.

Cordialement.

PS oui, du pain sur la planche il y en a eu : appli de cinq cents fenêtres, un an de travail pour tout passer au format WD16 avec améliorations au passage.

[frenchsting]

Beau boulot oui !!!

Je te conseille de passer en C/S le plus vite possible. Par contre, là, ça devrait être plus rapide que la migration.

Nous sommes en HF classic + HF55 et le projet (le plus urgent) est de passer en C/S afin de palier les problèmes d'index et autres blocages...

[tim501]

Un grand merci pour ta réponse rapide.
Je suis en train de travailler dessus et, étant de nature méfiante, je ne vais pas aller à la facilité qui consiste à modifier l'analyse ce qui rend la migration définitive. Je vais me ménager une sortie de secours en gérant les deux accès. Une petite classe s'impose de façon à standardiser tous mes projets...

Merci encore pour ton aide.

Cordialement.

[frenchsting]

Rien ne t'empêche de faire une sauvegarde de ton analyse (et du projet) avant le grand saut.

[tim501]

Oui, mais il faut de toute façon que l'appli puisse tourner à la fois en réseau et en locale, l'analyse étant partagée pour cause d'une notion de maison mère et de dépôts. Donc je n'ai pas le choix.
Si tu es intéressé par mes progrès dans la solution que j'aurais trouvée, fais le moi savoir ...

[frenchsting]

C'est toujours intéressant ce genre d'info...

[SevenSoftware]

Bonjour,

Tout à fait d'accord avec Yusep. Même si ça paraît plus long, la réécriture
est tellement plus efficace !

Après une migration et passage en C/S il faut, outre virer les fonctions obsoletes:
- Mettre les tables fichier en automatique (donc virer le code de 1er enregistrement, etc.. vu que la migration ne le fait pas)
- Remplacer les boucles HLitRecherche...HLitSuivant et les HFiltre par des requetes SQL
- Dans les autres HLItRecherche, mettre la nouvelle syntaxe pour les clés composées (surtout si les fichier sont passés en "sans espace")
- Remplacer un bon paquet de HLitRecherche par HLitRecherchePremier
- Si on a appliqué un gabarit... refaire presque toute l'IHM (!)
- Etc, etc...
- Tester tout. Corriger les 245 bugs restant. Retester.

Bon, OK, j'exagère un peu mais j'ai pas de bons souvenirs de migration...

[tim501]

Pour la migration c'est sûr que c'est un gros boulot contrairement à ce que pcsoft nous a vendu.
Vérifier toutes les lignes de code et rendre compatible d'accord mais tout réécrire est une mauvaise solution car impose un débogage et une période de rodage surtout quand ladite appli à 15 ans derrière elle. Si je me fie à mon expérience, l'application en question ayant demandé 3 ans de travail et un an de migration, je suis donc gagnant et je ne compte pas toutes les mises au point et autres subtilités apportées durant toutes ses années.
Être systématique peut coûter très cher tout en donnant des illusions de gain de temps. Ça peut à la rigueur se comprendre pour un petit projet, mais pour un projet conséquent il vaut mieux, à mon humble avis bien réfléchir avant de jeter le bébé avec l'eau du bain.