Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement WinDev [Windev 9 - DBF] Lenteur en multipostes

[Windev 9 - DBF] Lenteur en multipostes

11 réponses
Avatar
mel.forums
Bonjour le groupe.

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 ....


Merci d'avoir pris le temps de me lire.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Fredo MT
a écrit :
Bonjour le groupe.

Je développe une application en Windev 9 qui attaque des fichiers DBF
(clipper 5) via l'accès natif xBase.

Le problème : dès qu'un deuxième utilisateur lance l'application,
les temps de réponses augmentent considérablement.

J'ai refait un mini projet pour effectuer le test suivant :

- Via DBU : Création d'un fichier DBF à 2 champs (IDENT N10 et
LIBELLE C10). Ces 2 champs sont des index.
- Windev : Création d'un nouveau projet (multi utilisateurs),
importation de la table dans l'analyse et création d'une fenêtre
(fiche avec parcours) via le RAD (programmation procédurale, code de
création des fichiers, pas de rafraîchissement automatique).
- Ajout d'un HChangeRep en début de code d'initialisation du projet
- Modification de la fenêtre générée par le RAD pour la passer en
contexte indépendant.
- Génération de l'exécutable.
- Mise sur le réseau de l'exécutable et des fichiers.

Un utilisateur lance l'application et se retrouve sur la fenêtre en
mode parcours en 1 seconde : OK.
Un second utilisateur lance l'application et se retrouve également sur
la fenêtre en mode parcours, mais après avoir eu le splash screen
durant 6 à 7 secondes : ???

Remarques :
- le même accès via un programme DOS (Clipper) fonctionne très
bien.
- le serveur de fichiers actuel est un Novell 6.5 mais le même
problème apparaît sur un serveur Windows 2003

Tests effectués :

- Ouverture manuelle de la base (HDbOuvre et HDbIndex) : même
résultat (en remarquant au passage que le temps de réponse augmente
non pas sur le HDbOuvre mais sur le premier HDbIndex)
- Déclaration de la base dans l'analyse dans les différents formats
xBase proposés : idem.
- Création des fichiers par Windev (hCreatioSiInexistant) : pas
mieux.
- Copie de l'exécutable en local sur les 2 postes.

Questions :

- Quelqu'un -il déjà rencontré le problème ?
- Une âme charitable disposant d'un windev 10 ou 11 accepterait-elle
de faire ce test ?
- Une piste quelconque ....


Merci d'avoir pris le temps de me lire.




Bonjour,

Teste en fermant le fichier après chaque accès en lecture et/ou écriture
avec HFerme, et regarde les performances.

Tiens nous au courant.
Avatar
mel.forums
Fredo MT a écrit :


Bonjour,

Teste en fermant le fichier après chaque accès en lecture et/ou écr iture
avec HFerme, et regarde les performances.

Tiens nous au courant.



Bonjour,

merci de t'intéresser à mon problème !
Je vais refaire le test mais il me semble l'avoir essayé ==> perte de
l'ordre de parcours sur l'appel à hlitsuivant.
Avatar
nwjb
Le Tue, 21 Nov 2006 10:55:09 +0100, a écrit:


Fredo MT a écrit :


Bonjour,

Teste en fermant le fichier après chaque accès en lecture et/ou écriture
avec HFerme, et regarde les performances.

Tiens nous au courant.



Bonjour,

merci de t'intéresser à mon problème !
Je vais refaire le test mais il me semble l'avoir essayé ==> perte de
l'ordre de parcours sur l'appel à hlitsuivant.




Voir les paramètres de gestion des locks sur le serveur.

--
J.Bratières

Enlever paspub pour répondre
Please remove paspub when answering
Avatar
Antoine
Quand un seul utilisateur accède à un fichier par le réseau, Windows
travaille dessus comme si le fichier était en local (il le récupère en
entier, ou certains bouts dans le cache local). Mais dès que plusieurs
utilisateurs s'en servent en écriture, Windows ne plus plus faire cela, donc
il lit et écrit sur le réseau. En fait, ce n'est pas l'accès à plusieurs qui
rame, c'est l'accès monoutilisateur qui est boosté.

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

Antoine


a écrit dans le message de news:

Bonjour le groupe.

Je développe une application en Windev 9 qui attaque des fichiers DBF
(clipper 5) via l'accès natif xBase.

Le problème : dès qu'un deuxième utilisateur lance l'application,
les temps de réponses augmentent considérablement.

J'ai refait un mini projet pour effectuer le test suivant :

- Via DBU : Création d'un fichier DBF à 2 champs (IDENT N10 et
LIBELLE C10). Ces 2 champs sont des index.
- Windev : Création d'un nouveau projet (multi utilisateurs),
importation de la table dans l'analyse et création d'une fenêtre
(fiche avec parcours) via le RAD (programmation procédurale, code de
création des fichiers, pas de rafraîchissement automatique).
- Ajout d'un HChangeRep en début de code d'initialisation du projet
- Modification de la fenêtre générée par le RAD pour la passer en
contexte indépendant.
- Génération de l'exécutable.
- Mise sur le réseau de l'exécutable et des fichiers.

Un utilisateur lance l'application et se retrouve sur la fenêtre en
mode parcours en 1 seconde : OK.
Un second utilisateur lance l'application et se retrouve également sur
la fenêtre en mode parcours, mais après avoir eu le splash screen
durant 6 à 7 secondes : ???

Remarques :
- le même accès via un programme DOS (Clipper) fonctionne très
bien.
- le serveur de fichiers actuel est un Novell 6.5 mais le même
problème apparaît sur un serveur Windows 2003

Tests effectués :

- Ouverture manuelle de la base (HDbOuvre et HDbIndex) : même
résultat (en remarquant au passage que le temps de réponse augmente
non pas sur le HDbOuvre mais sur le premier HDbIndex)
- Déclaration de la base dans l'analyse dans les différents formats
xBase proposés : idem.
- Création des fichiers par Windev (hCreatioSiInexistant) : pas
mieux.
- Copie de l'exécutable en local sur les 2 postes.

Questions :

- Quelqu'un -il déjà rencontré le problème ?
- Une âme charitable disposant d'un windev 10 ou 11 accepterait-elle
de faire ce test ?
- Une piste quelconque ....


Merci d'avoir pris le temps de me lire.
Avatar
mel.forums
nwjb a écrit :


Voir les paramètres de gestion des locks sur le serveur.

--
J.Bratières

Enlever paspub pour répondre
Please remove paspub when answering



Antoine a écrit :

Quand un seul utilisateur accède à un fichier par le réseau, Windows
travaille dessus comme si le fichier était en local (il le récupère en
entier, ou certains bouts dans le cache local). Mais dès que plusieurs
utilisateurs s'en servent en écriture, Windows ne plus plus faire cela, donc
il lit et écrit sur le réseau. En fait, ce n'est pas l'accès à pl usieurs qui
rame, c'est l'accès monoutilisateur qui est boosté.

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

Antoine



Merci à vous deux.

Je vérifie ces paramètres et reviendrait vers vous. Néanmoins, deux
détails interressant :
- Pas de problème sur ces même fichiers avec une appli DOS
- Pas de problème avec un fichier HF et non DBF.

Du coup, je me demande si le système de verrou intervient réellement
...
Avatar
mel.forums
Autre info : si je change le type d'accès dans la connexion
(utilisation de OLE DB dBase au lieu de Accès natif), je conserve un
temps de réponse correct lors de l'accès du deuxième utilisateur.

Par contre, je perd les informations automatique de conflit (fenêtre
Windev affichant les différentes valeurs de champs : lors de la
lecture, maintenant et à enregistrer) ....

Celà inspire-t-il quelqu'un ???
Avatar
mat
wrote:
Un utilisateur lance l'application et se retrouve sur la fenêtre en
mode parcours en 1 seconde : OK.
Un second utilisateur lance l'application et se retrouve également sur
la fenêtre en mode parcours, mais après avoir eu le splash screen
durant 6 à 7 secondes : ???

Remarques :
- le même accès via un programme DOS (Clipper) fonctionne très
bien.




Bonjour,

c'est le même phénomène que nous avions avec HF 7/7.5/8. Dans cette
dernière version, ils ont amélioré l'accès multi-utilisateur pour HF. Il
se peut que cela ne vaut pas pour DBF.

Selon PC Soft, c'était un problème dû à Windows, mais comme tu constate
ce problème n'existe qu'avec Windev, non plus p.ex. avec Paradox et
Foxpro pour Windows. C'est dans la nature des choses qu'Antoine
représente cette idée. Qu'elle ne tien pas le bout ne semble pas intéresser.

A mon avis c'est un problème du type d'accès aux fichiers. Je joins un
lien à un thread long et complexe. Le représentant officieux de PC Soft
explique bien que même les requêtes accèdent au données sur le serveur,
provoquant ces ralentis, normaux selon lui. Ted mentionne comment Windev
accède aux fichiers, via API. Je ne comprends pas grande chose à la
programmation au niveau du système d'exploitation, mais on en a pas
besoin de comprendre beaucoup pour constater que certains accès fichier
de Windev sont beaucoup moins efficace que ceux d'autres produits sur le
marché.

http://groups-beta.google.com/group/fr.comp.developpement.agl.windev/browse_thread/thread/c7f5c82a724d04a6/1c2b55dd9f4d370f?lnk=gst&q=mnobs+r%C3%A9seau&rnum(#1c2b55dd9f4d370f

Salutations
Mat
Avatar
mel.forums
mat a écrit :

wrote:
> Un utilisateur lance l'application et se retrouve sur la fenêtre en
> mode parcours en 1 seconde : OK.
> Un second utilisateur lance l'application et se retrouve également sur
> la fenêtre en mode parcours, mais après avoir eu le splash screen
> durant 6 à 7 secondes : ???
>
> Remarques :
> - le même accès via un programme DOS (Clipper) fonctionne très
> bien.


Bonjour,

c'est le même phénomène que nous avions avec HF 7/7.5/8. Dans cette
dernière version, ils ont amélioré l'accès multi-utilisateur pour HF. Il
se peut que cela ne vaut pas pour DBF.

Selon PC Soft, c'était un problème dû à Windows, mais comme tu co nstate
ce problème n'existe qu'avec Windev, non plus p.ex. avec Paradox et
Foxpro pour Windows. C'est dans la nature des choses qu'Antoine
représente cette idée. Qu'elle ne tien pas le bout ne semble pas int éresser.

A mon avis c'est un problème du type d'accès aux fichiers. Je joins un
lien à un thread long et complexe. Le représentant officieux de PC So ft
explique bien que même les requêtes accèdent au données sur le se rveur,
provoquant ces ralentis, normaux selon lui. Ted mentionne comment Windev
accède aux fichiers, via API. Je ne comprends pas grande chose à la
programmation au niveau du système d'exploitation, mais on en a pas
besoin de comprendre beaucoup pour constater que certains accès fichier
de Windev sont beaucoup moins efficace que ceux d'autres produits sur le
marché.

http://groups-beta.google.com/group/fr.comp.developpement.agl.windev/brow se_thread/thread/c7f5c82a724d04a6/1c2b55dd9f4d370f?lnk=gst&q=mnobs+r%C3 %A9seau&rnum(#1c2b55dd9f4d370f

Salutations
Mat



Bonjour,

j'avais déjà lu ce looooong post qui m'avait hélas conforté dans
l'idée que certains fichiers / BD généraient des temps de réponses
plus long avec Windev (ce qui ne veut pas dire que l'inverse n'arrive
pas !!! mais pour l'instant seul ce cas de figure m'interesse : Windev
+ DBF)

J'éspérait (et continue ...) tout de même de croire en l'éxistence
d'une solution (contournement, manière de coder différente, patch PC
Soft, .... ).

En attendant, à la manière de Mat dans son thread, je constate un
fait : un accès multi-utilisateurs sur un fichier DBF est long.

Néanmoins, plusieurs réponses (dans ce thread, sur ce même groupe,
dans la FAQ PC Soft et sur d'autre site) pointent du doigt les oplocks
(je rappel que j'ai constaté ce problème sur un serveur Windows 2003
mais EGALEMENT avec un serveur Novell 6.5). N'étant pas forcemment au
top dans ce domaine, j'ai effectué des recherches sur la toile et
désactivé (tout du moins il me semble ;) ) par modification de la BdR
(client et serveur pour le 2003) la gestion des opportunistic locking.

Si quelqu'un à plus de renseignement sur le sujet, qu'il n'hésite
surtout pas, je suis preneur !
Avatar
mat
wrote:
...
Néanmoins, plusieurs réponses (dans ce thread, sur ce même groupe,
dans la FAQ PC Soft et sur d'autre site) pointent du doigt les oplocks
(je rappel que j'ai constaté ce problème sur un serveur Windows 2003
mais EGALEMENT avec un serveur Novell 6.5). N'étant pas forcemment au
top dans ce domaine, j'ai effectué des recherches sur la toile et
désactivé (tout du moins il me semble ;) ) par modification de la BdR
(client et serveur pour le 2003) la gestion des opportunistic locking.

Si quelqu'un à plus de renseignement sur le sujet, qu'il n'hésite
surtout pas, je suis preneur !





1) c'est bien OpLocks qui pose de problème, mais ce n'est pas la cause
mais le symptôme car sinon le problème devrait exister avec tous les
autres produits sur le marché. Je ne m'intéresse plus tellement pourquoi
Windev a un problème avec OpLocks: MSAccess, Paradox pour Windows,
Visual Foxpro ne l'ont pas!

2) Dans mon expérience, il faut désactiver les Oplocks sur les clients,
pas le server, sinon la performance souffre énormément et je n'ai jamais
constaté de problèmes avec OpLocks activé dans LanManServer: attention,
je parle bien de service pas de machines, car le serveur peut aussi être
client
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanWorkstationParameters]


Salutations
Mat
Avatar
mat
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
1 2