Je d=E9veloppe une application en Windev 9 qui attaque des fichiers DBF
(clipper 5) via l'acc=E8s natif xBase.
Le probl=E8me : d=E8s qu'un deuxi=E8me utilisateur lance l'application,
les temps de r=E9ponses augmentent consid=E9rablement.
J'ai refait un mini projet pour effectuer le test suivant :
- Via DBU : Cr=E9ation d'un fichier DBF =E0 2 champs (IDENT N10 et
LIBELLE C10). Ces 2 champs sont des index.
- Windev : Cr=E9ation d'un nouveau projet (multi utilisateurs),
importation de la table dans l'analyse et cr=E9ation d'une fen=EAtre
(fiche avec parcours) via le RAD (programmation proc=E9durale, code de
cr=E9ation des fichiers, pas de rafra=EEchissement automatique).
- Ajout d'un HChangeRep en d=E9but de code d'initialisation du projet
- Modification de la fen=EAtre g=E9n=E9r=E9e par le RAD pour la passer en
contexte ind=E9pendant.
- G=E9n=E9ration de l'ex=E9cutable.
- Mise sur le r=E9seau de l'ex=E9cutable et des fichiers.
Un utilisateur lance l'application et se retrouve sur la fen=EAtre en
mode parcours en 1 seconde : OK.
Un second utilisateur lance l'application et se retrouve =E9galement sur
la fen=EAtre en mode parcours, mais apr=E8s avoir eu le splash screen
durant 6 =E0 7 secondes : ???
Remarques :
- le m=EAme acc=E8s via un programme DOS (Clipper) fonctionne tr=E8s
bien.
- le serveur de fichiers actuel est un Novell 6.5 mais le m=EAme
probl=E8me appara=EEt sur un serveur Windows 2003
Tests effectu=E9s :
- Ouverture manuelle de la base (HDbOuvre et HDbIndex) : m=EAme
r=E9sultat (en remarquant au passage que le temps de r=E9ponse augmente
non pas sur le HDbOuvre mais sur le premier HDbIndex)
- D=E9claration de la base dans l'analyse dans les diff=E9rents formats
xBase propos=E9s : idem.
- Cr=E9ation des fichiers par Windev (hCreatioSiInexistant) : pas
mieux.
- Copie de l'ex=E9cutable en local sur les 2 postes.
Questions :
- Quelqu'un -il d=E9j=E0 rencontr=E9 le probl=E8me ?
- Une =E2me charitable disposant d'un windev 10 ou 11 accepterait-elle
de faire ce test ?
- Une piste quelconque ....
Désolé, je ne voulais pas lancer une polémique... En voyant le post initial sur le pb, j'avais un souvenir de ce pb pour m'être aussi posé la question à l'époque (2-3 ans en arrière), et j'ai fait une recherche Google qui m'a remonté le .pdf ... d'où le fait que je l'indique dans ma réponse.
Mais je n'ai pas testé plus loin et j'avoue ne pas savoir si le problème vient plutôt d'une mauvaise gestion réseau de Windev dans cet accès natif.
Et pour rebondir sur ta dernière phrase, Mat, pour ne pas perdre nos clients justement, nous les soignons et nous n'utilisons plus HF, car suite à de trop nombreux problèmes nous avons choisi une autre base de données avec un accès "à nous" et non pas un accès natif. Ceci dit, je n'ai pas testé le HF Client/Serveur qui fait peut-être bien son boulot, mais nous attendons qu'il fasse ses preuves avant d'oser imaginer l'utiliser...
Antoine
"mat" a écrit dans le message de news:
Antoine wrote:
Voir un pdf de pcsoft qui explique cela, notamment le système de verrou opportuniste de Windows, page 2 de ce pdf: http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf
...
Si ce document est toujours publié, faudrait faire un procès à PC Soft pour dénigrer leurs clients et Windows. Ils savent parfaitement que les problèmes décrits sont dans leur ampleur une particularité de Windev qui n'ont strictement rien à voir avec Windows et non plus avec les développeurs. Nous avons fournis nos preuves il y a 2 ans et attendons toujours une preuve du contraire.
D'autre part c'est vrai que les performances des requêtes Windev/HF se sont améliorés avec l'arrivée de WD9 et 10, ce que nous apprécions, même si elles sont toujours loin du standard dans ce domaine. Au même temps c'est encore une preuve où se trouve le vrai coupable. Mais je suis convaincu que vous trouverez encore des paroles pour diminuer le problème ou dénigrer vos clients, n'est-ce pas, Antoine? :-)
Mat
Hello,
Désolé, je ne voulais pas lancer une polémique... En voyant le post initial
sur le pb, j'avais un souvenir de ce pb pour m'être aussi posé la question à
l'époque (2-3 ans en arrière), et j'ai fait une recherche Google qui m'a
remonté le .pdf ... d'où le fait que je l'indique dans ma réponse.
Mais je n'ai pas testé plus loin et j'avoue ne pas savoir si le problème
vient plutôt d'une mauvaise gestion réseau de Windev dans cet accès natif.
Et pour rebondir sur ta dernière phrase, Mat, pour ne pas perdre nos clients
justement, nous les soignons et nous n'utilisons plus HF, car suite à de
trop nombreux problèmes nous avons choisi une autre base de données avec un
accès "à nous" et non pas un accès natif. Ceci dit, je n'ai pas testé le HF
Client/Serveur qui fait peut-être bien son boulot, mais nous attendons qu'il
fasse ses preuves avant d'oser imaginer l'utiliser...
Antoine
"mat" <NoSPAM-mnobs@windasso.org> a écrit dans le message de news:
4shl5lFvpuraU1@mid.individual.net...
Antoine wrote:
Voir un pdf de pcsoft qui explique cela, notamment le système de verrou
opportuniste de Windows, page 2 de ce pdf:
http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf
...
Si ce document est toujours publié, faudrait faire un procès à PC Soft
pour dénigrer leurs clients et Windows. Ils savent parfaitement que les
problèmes décrits sont dans leur ampleur une particularité de Windev qui
n'ont strictement rien à voir avec Windows et non plus avec les
développeurs. Nous avons fournis nos preuves il y a 2 ans et attendons
toujours une preuve du contraire.
D'autre part c'est vrai que les performances des requêtes Windev/HF se
sont améliorés avec l'arrivée de WD9 et 10, ce que nous apprécions, même
si elles sont toujours loin du standard dans ce domaine. Au même temps
c'est encore une preuve où se trouve le vrai coupable. Mais je suis
convaincu que vous trouverez encore des paroles pour diminuer le problème
ou dénigrer vos clients, n'est-ce pas, Antoine? :-)
Désolé, je ne voulais pas lancer une polémique... En voyant le post initial sur le pb, j'avais un souvenir de ce pb pour m'être aussi posé la question à l'époque (2-3 ans en arrière), et j'ai fait une recherche Google qui m'a remonté le .pdf ... d'où le fait que je l'indique dans ma réponse.
Mais je n'ai pas testé plus loin et j'avoue ne pas savoir si le problème vient plutôt d'une mauvaise gestion réseau de Windev dans cet accès natif.
Et pour rebondir sur ta dernière phrase, Mat, pour ne pas perdre nos clients justement, nous les soignons et nous n'utilisons plus HF, car suite à de trop nombreux problèmes nous avons choisi une autre base de données avec un accès "à nous" et non pas un accès natif. Ceci dit, je n'ai pas testé le HF Client/Serveur qui fait peut-être bien son boulot, mais nous attendons qu'il fasse ses preuves avant d'oser imaginer l'utiliser...
Antoine
"mat" a écrit dans le message de news:
Antoine wrote:
Voir un pdf de pcsoft qui explique cela, notamment le système de verrou opportuniste de Windows, page 2 de ce pdf: http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf
...
Si ce document est toujours publié, faudrait faire un procès à PC Soft pour dénigrer leurs clients et Windows. Ils savent parfaitement que les problèmes décrits sont dans leur ampleur une particularité de Windev qui n'ont strictement rien à voir avec Windows et non plus avec les développeurs. Nous avons fournis nos preuves il y a 2 ans et attendons toujours une preuve du contraire.
D'autre part c'est vrai que les performances des requêtes Windev/HF se sont améliorés avec l'arrivée de WD9 et 10, ce que nous apprécions, même si elles sont toujours loin du standard dans ce domaine. Au même temps c'est encore une preuve où se trouve le vrai coupable. Mais je suis convaincu que vous trouverez encore des paroles pour diminuer le problème ou dénigrer vos clients, n'est-ce pas, Antoine? :-)
