[WD 7.5 / 8.0] Requêtes sur Hyperfile e t lenteurs réseau
mat
Nous avons découvert une anomalie concernant les requêtes de Windev sur
Hyperfile et demandé PC Soft aujourd'hui de la corriger.
Préambule: Entre mai et juillet 2003 nous avions fait beaucoup de tests
en réseau, à cause de lenteurs constatées, et communiqué le résultat à
PC Soft. En octobre 2003, la version 75206g éliminait les problèmes
constatés. Au moins nous croyions. Nous sommes maintenant sous WD8 et
après un témoignage récent que le problème persiste lorsqu’un des
fichiers concernés est en modification, nous avons refait nos tests,
aussi avec l'ancien projet WD7.5 sous la version 75206g. Effectivement
le problème existe toujours, et avait déjà existé sous la 206g,
simplement nous n'avions pas testé avec des modifications à l'époque...
Le Service Technique a réagit rapidement à notre communication la
semaine passée, mais il ne répète que le point de vue publié en octobre
2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ
2861). Ce document place la responsabilité pour les lenteurs en réseau
dans le coin de Microsoft Windows (OpLocks) et les développeurs (mauvais
code). Je n'ai aucun doute que ces deux points peuvent jouer un rôle.
Mais nous avons également des expériences avec Paradox, Access, Delphi
et Visual Foxpro. Avec aucun de ces produits nous remarquons des
ralentissements comparables en réseau. Alors, un problème général de
Windows qui se fait noter seulement avec Windev / HF ???
Extraits de ce document, concernant les verrous opportunistes (OpLocks)
de Windows:
..."Un mécanisme important des serveurs Windows est le "verrou
opportuniste". Ce mécanisme est propre aux serveurs Windows et est
totalement indépendant de Windev et de Hyper File."...
..."Il est tout à fait normal de constater des différences de
performances dès la 2° connexion en mode modification. Notez que les
performances, pour un réseau correctement dimensionné, seront identiques
pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux
utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme
de gestion du verrou opportuniste de Windows qui implique cela."...
CONSTATS
--------
1) Le premier extrait implique que Windev/HF n'y sont pour rien, c'est
la faute à Windows. Mais HF et OpLocks sont aussi indépendant l'un de
l'autre comme Windev de Windows. Nous avons refait des tests sous
Paradox et Access 2000. Aucun de ces environnements ne montre des
ralentissements en réseau comparable à Windev/HF. La même chose valait
l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
clairement une interaction de Windev/HF avec Windows qui est responsable
des ralentissements.
2) Le 2e extrait ne tient pas compte du contexte: oui, le ralentissement
d'une requête est normal lorsqu’un des fichiers est en modification sur
un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous:
Paradox + 16%
Access 2000 + 18%
Windev/HF + 270%
Ces chiffres expliquent pourquoi certains développeurs Windev sont
mécontents. J'aimerais ajouter que la version de Paradox est la 7 de
1996, donc pas exactement une technologie d'avant-garde.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière
plan. Mais ceci ne fonctionne plus quand il faut totaliser une rubrique
ou compter les enregistrements rendus ou trier une requête multi-fichier
sur autre chose qu'une clé de liaison. La recommandation de certains
gens qu'un index composé des rubriques de trie résout le problème ne
sert à rien lorsque plusieurs fichiers sont utilisés.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un
poste client utilise un fichier temporaire sur le SERVEUR, au lieu du
disque local. C'est à notre avis la raison principale des
ralentissements: c'est plus lent d'écrire sur le serveur que sur son
disque local et en plus cela provoque des conflits lors d'un 2e accès
car il doit gérer plusieurs contextes du "même fichier". On peut
facilement vérifier ce comportement: on ouvre la même fenêtre avec une
table alimentée par une requête EN LECTURE SEUL sur le Serveur et un
poste client. On modifie sur le serveur un seul champ de la table et le
temps de réponse de la requête sur le poste client passe IMMéDIATEMENT
au mode "modification multi-utilisateur", donc + 270%, et ceci pour tout
le monde. POURTANT IL N'Y A AUCUNE MODIFICATION DU FICHIER DE DONNÉES,
AVEC UNE REQUÊTE EN LECTURE SEULE, UNIQUEMENT DANS LA TABLE, C'EST-A
DIRE LA REQUETE SUR UN AUTRE PC.
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt
que dû au réseau: si le ralentissement venait uniquement du fait que le
serveur doit interrompre le verrou OpLock, alors le retard serait
toujours le même dans le réseau. En réalité le ralentissement en
secondes dépend de la performance du PC client. Alors il s'agit bien
d'une question de traitement et ne pas de réseau!
CONCLUSIONS
-----------
Dès qu'il y a modification d'un des fichiers d'une requête, qu'il faut
obtenir le nombre d'enregistrements, calculer une somme, accéder un
enregistrement vers la fin du fichier SQL ou trier la requête sur autre
chose que la clé de liaison de deux fichiers, les requêtes Windev sur HF
commencent à traîner et parfois deviennent extrêmement longues.
La vérification avec d'autres produits montre que la déclaration de PC
Soft, que cela est le comportement normal sous un serveur Windows est
incorrect. En réalité, il s'agit
- soit du résultat d'une architecture voulu,
- soit d'un dysfonctionnement accidentel,
des requêtes HF, résultant dans l'usage du serveur pour la gestion du
fichier temporaire d'une requête, aussi lorsqu'elle est EN LECTURE
SEULE. Ce comportement est à notre avis responsable pour les importants
ralentissements lors de modifications.
Les autres produits testés ne sont pas perturbés par les OpLocks de
Windows, nous croyons parce qu'ils ne font tout simplement que ce qu'ils
doivent: lire les données sur le serveur, les transférer sur disque
local et les traiter localement. Aucun conflit possible entre le fichier
SQL d'un poste et l'autre.
Nous avons investi beaucoup de temps dans un projet important pour nous
et espérons que les requêtes HF seront mises au point bientôt, une fois
pour toutes. D’autant plus qu’il nous paraît pas difficile de s’assurer
que le fichier temporaire d’une requête en lecture seul réside sur le PC
local et ne pas sur le serveur. Nous pensons qu’avec cela les lenteurs
réclamées vont disparaître.
La version annoncée de client/serveur n'est pas une bonne solution pour
les utilisateurs d'une BD en partage de fichiers, car le traitement des
données fonctionne d'une autre manière et l'application doit être
partiellement réécrite. Si elle était payante, c'est en plus le client
qui devrait payer pour éviter un dysfonctionnement de la version normale.
Mathias Nobs
Résultats détaillés de nos tests
--------------------------------
Serveur : P4, 2.4Ghz
Clients : P1 = PIII, 650Mhz P2 = PIII, 500Mhz
Test Access: Serveur PIII 500Mhz, P1 PIII 650Mhz, P2 P4 2.4Ghz
OS : W2K Pro sur tous les PC
En 2003, le comportement avec données sur NT4 Serveur et W2K
Server à été identique à W2K Pro.
Utilisation OpLocks : Serveur = 1, Clients = 0
Utilisation network cache: Serveur = 1, Clients = 0
Protocole : TCP/IP
Antivirus : désactivé partout
Usage réseau : exclusif pour les tests
Windev HSecurité: par défaut
Manipul.Fichiers: par défaut
Fichiers: Entêtes et lignes de commandes, liés par ID. Même
structures et données pour WD et Paradox. Access2000
structure fichier similaire mais autres données.
Redémarrage du serveur après chaque série d'un produit.
Temps en secondes pour ouvrir la fenêtre mesuré du début des
déclarations globales à l'initialisation de la fenêtre avec affichage
par Info(HNbRec(sql_test),TimeDifference(vStartTime,TimeSys)),
respectivement Info(TimeDifference(vStartTime,TimeSys)).
Produit P1 = Lecture P2 = Lecture P2 = Modif sur fichier
P1 = Lecture P1 = Lecture
---------------------------------------------------------------------
Windev / HF 4.9 6.3 +29% 23.3 +375% / +270%
HNbRec
4041 enr.
Windev / HF 9.3 10.7 +15% 27.4 +195% / +156%
WD8 Aff. auto
nb enreg.
Windev / HF 0.5 * 0.6 +20% * 0.7 * + 40% / + 17%
sans nb enr./
sans Order By
Paradox 7 1.9 1.9 + 0% 2.2 + 16% / + 16%
4428 enr.
Access 2000 5.5 2.2 -60% ** 2.6 - 53% / + 18%
118 enr.
* continuation de la lecture en arrière plan. Accès aux enregistrements
non lus impossible, sinon même ralentissement que les tests précédents.
** fichier de données MDB déjà ouvert par l'autre poste = accès plus rapide.
Fenêtre Windev créé par le RAD avec une table fichier alimenté par une
requête Windev avec le code SQL suivant:
select * from Contract,ContractDetail
where ContractDetail.IDContract = Contract.IDContract
Lancement de la requête dans les déclarations globales de la fenêtre RAD:
IF HFileExist(sql_test)=False THEN
gbRequeteLocal = True
// Query initialization sql_test
HExecuteQuery(sql_test,hQueryDefault)
IF ErrorOccurred THEN
// Error message display
Error("Error when initializing the query correspondant aux
fichier :
sql_test")
// window closing
Close()
END
ELSE
gbRequeteLocal = False
END
free
> pour
> les utilisateurs d'une BD en partage de fichiers, car le traitement
> des données fonctionne d'une autre manière et l'application doit être
> partiellement réécrite. Si elle était payante, c'est en plus le client
> qui devrait payer pour éviter un dysfonctionnement de la version
> normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite
? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté
client pour les envoyer sur le serveur. Tout ceci peut facilement être
envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
--
Emmanuel
mat
Bonjour Emmanuel,
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce
qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement
la preuve du contraire. Tout ce qui aide la cause...
free
> free wrote:
>>> La version annoncée de client/serveur n'est pas une bonne solution
>>> pour
>>> les utilisateurs d'une BD en partage de fichiers, car le traitement
>>> des données fonctionne d'une autre manière et l'application doit
>>> être partiellement réécrite. Si elle était payante, c'est en plus
>>> le client qui devrait payer pour éviter un dysfonctionnement de la
>>> version normale.
>>
>>
>> En quoi peux-tu affirmer que l'application doit partiellement être
>> réécrite ? Tu as tester le C/S ?
>> Pour moi il suffirait de plugger les ordres ainsi que les requetes
>> du coté client pour les envoyer sur le serveur. Tout ceci peut
>> facilement être envisageable au moment de la compilation.
>>
>> Concernant le coût éventuel de cette évolution (C/S) j'attends les
>> nouvelles plaquettes.
>>
>> Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
>>
> ce qui concerne mySQL, entre autre sur ce forum. J'accèpte
> volontièrement la preuve du contraire. Tout ce qui aide la cause...
OK. Pour moi il ne faut pas confondre le C/S de l'éditeur et la
programmation avec un SGBD C/S du marché issue d'une migration.
La problématique rencontrée par certains d'entre nous vient du fait même de
leur mode de programmation. Quand on programme en mode fichier (à la
HF-Like) que ce soit avec HyperFile, avec MySQL, avec Oracle tu auras
_TOUJOURS_ des temps quasi comparables. Quand on programme en requetes, il
apparait un problème au niveau du langage SQL, chose qui est générale entre
les différents SGBD (il suffit de voir les fonctions DECODE de Oracle et IF
de MySQL). Autre problème rencontré et que j'ai déjà présenté : certains
pensent que l'écriture avec une méga requête va réduire leur temps de
traitement ce qui est parfois faux...
Pour moi, dans l'état actuel des choses, il est préférable d'attendre la
solution de l'éditeur et de trouver rapidement une réponse à tes questions :
quel est l'impact dans mes applications existantes ? quel est le cout ?
--
Emmanuel Lecoester
www.sqlmanagerx.com
JBT
Merci avant tout "Mat" pour la précision de ton message.
Pour ces raisons j'avais des doutes sur la poursuite de l'utilisation
du système de partage actuel. Actuellement je n'avais quasiment que des
installations avec Linux/Samba, car là aucun ralentissement de ce type.
Avec l'arrivée du client/serveur, je ne suis pas certain qu'un jour
nous ayons le fin mot de l'affaire. En effet, aucun ralentissement de
ce type n'est constaté en mode client/serveur d'après mes tests. Mais
il ne s'agit encore que de la bêta version sur laquelle la
communication n'est pas encore possible :-(
Adrien
fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
a premiére vue, les performances sont meilleures, c'est un bon début.
A+
Adrien.
"free" <e...@netcourrier.com> a écrit dans le message de
news:4150575b$0$17699$626a...@news.free.fr...
Manu
> fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
> a premiére vue, les performances sont meilleures, c'est un bon début.
Nickel. Cela me conforte dans l'idée d'un non impact sur les dev et
implicitement d'un coup moindre ;-)
--
Emmanuel
Eric Demeester
<adrien...@ifrance.com> ecrivait (wrote) :
Bonsoir Adrien,
> j'ai la version bêta du c/s et il suffit de l'installer, copier les
> fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
> a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps
d'accès entre HF et HF C/S ?
Amicalement,
--
Eric
Adrien
toutefois, voici un test réél
requête complexe avec jointure.
base = 100 000 enregs avec 5 postes accédant à la base en simultané.
resultat = 1 000 enregs
HF : 7 s.
HF C/S : 2 sec
je te conseilles par contre de te faire ta propre opinion. tu envoie un mail
à pcsoft et ils t'envoient leur bêta version.
A+
Adrien.
"Eric Demeester" <eric+...@galacsys.net> a écrit dans le message de
news:v0i3l0hr8ke14p4f2...@4ax.com...
ted
Salut,
Ton post semble vouloir être contructif, pourtant il y a pas mal
d'incohérences et de points sombres que je me permets de relever.
Car il est vrai que j'aimerai comme tout développeur Windev qui utilise
Hyperfile que celui-ci soit toujours plus rapide. Mais des messages comme
celui-là peuvent mettre le doute dans l'esprit de personnes qui ne
l'utilisent pas. Et c'est en cela que je me permets de te répondre, car
Hyperfile est une partie intégrante de nos applications et de ce fait
c'est une bonne partie de notre gagne pain.
Notre expérience avec Hyperfile est plus que positive. Les évoltutions
qu'il y a eu notament entre la version 5 et la version 7 étaient plus que
positives. Il restait à notre goût un point noir pour les réseaux
distant, et Pcsoft nous propose enfin une version C/S.
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la
version C/S. Il semble que tu possèdes des élements de test interressant.
Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une
ligne dans le code de l'application
> Le Service Technique a réagit rapidement à notre communication la
> semaine passée, mais il ne répète que le point de vue publié en
> octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver
> sous FAQ 2861).
> identiques pour 2 ou 50 postes. Les performances sont alors similaires
> aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell.
> C'est le mécanisme de gestion du verrou opportuniste de Windows qui
> implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres
seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce
document avec d'autres type de serveurs nous n'avons pas observé de
changement brusque des perfomances au deuxième utilisateurs. Il y a donc
pour nous bien un lien spécifiques avec les serveurs NT.
> l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
> ralentissement d'une requête est normal lorsqu’un des fichiers est en
> modification sur un autre poste. Mais en chiffres ça veut dire quoi ?
> Chez nous: Paradox + 16%
> Access 2000 + 18%
> Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit
de base de données avec les mêmes structures ?
dans notre société, nous avons également fait des tests.
Nous avons obtenu des résultat très différents en fonction de la taille
des enregistrements.
La différence de vitesse se fait sentir pour les fichiers qui ont des
enregistrements de petites tailles.
Pour des fichiers avec de très gros enregistrements, il y a peu ou même
pas de différence.
Dans nos test la charnière se trouvait à unne taille d'enregistrement
entre 250 et 300 octets.
Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
>
> 3) Windev cache les lenteurs de ses requêtes en les exécutant en
> arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un
confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres
bases de données telle que Oracle par exemple.
Dans une application tu préfères attendre 10 secondes sans ne pourvoir
rien faire, ou avoir un début de résultat immédiatement avec la
possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre
la recherche pour lancer une autre recherche ?
> La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
> utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en
plus des indexes qui correspondent a tes tris cela sera plus rapides.
Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre
des index sur toutes les rubriques. Il faut mettre les index sur les
rubriques qui sont le plus souvent en critères, et surtout qui sont
sucéptibles d'être les plus discréminentes.
> 4) Le plus déconcertant est la découverte qu'une requête exécutée sur
> un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très
affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il
créé ?
Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir
paramétrer l'emplacement d'un tel fichier.
Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
> 5) Autre indice que les lenteurs de Windev / HF sont faits maison
> plutôt que dû au réseau: si le ralentissement venait uniquement du
> fait que le serveur doit interrompre le verrou OpLock, alors le retard
> serait toujours le même dans le réseau. En réalité le ralentissement
> en secondes dépend de la performance du PC client. Alors il s'agit
> bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas
C/S. Les perfomances dépendrons donc toujours AUSSI du poste client.
C'est chaque poste client qui effectue ses propre recherches. Chaque
poste client fait des lectures au poste sur lequel sont les fichiers. Les
perfomances dépendant donc du poste serveur et des caches qu'il met à
disposition, mais aussi de la rapidité avec laquelle les demandes sont
effcetuées par le poste client.
Shématiquement on peut facilment imaginer comment cela fonctionne :
Les données sont lues sur le poste serveur et sont rappatriés sur le
poste client. Si les caches sont activés, il peut y avoir plus de données
que ce que le client a demandé, et le tout reste dans le cache du poste
local. Selon la requête et les données déjà lues, le poste client va
faire d'autres lectures sur le serveur (ici variaions possibles en
fonction du poste client). S'il y a des élements dans le cache local et
que les données à lire sont dans ce cache c'est autant de lecture
"instantannées". Sans cache chaque nouvelle lecture représente un nouvel
accès au réseau.
> CONCLUSIONS
> -----------
Ma conclusion, est que tu as "oublié" pas mal de chose mais que tu es
très affirmatif dans tout ce que tu dis.
C'est un peu dommage car l'idée d'apporter ton experience pour faire
évoluer Hyperfile n'était pas mauvaise.
> La version annoncée de client/serveur n'est pas une bonne solution
> pour les utilisateurs d'une BD en partage de fichiers, car le
> traitement des données fonctionne d'une autre manière et l'application
> doit être partiellement réécrite.
Télécharge la beta et tu verras que c'est faux.
Tu n'as pas besoins de changer quoi que se soit à part la connexion.
Tu pourras par la suite utiliser plus de requêtes ou de vues, plutôt que
des filtres si tu veux. Mais nos tests nous ont montrés que les filtres
et parcours directs fonctionnent très rapidement sans le moindre
changenement dans nos codes.
De plus les perfomances restent stables seul ou à plusieurs postes.
En c/s on devient indépendant des caches du réseau.
En plus si avec cette version tu constates toujours tes pb de perf. tu
auras de nouveaus arguments, car les "OpsLock" de Windows seront cette
fois-ci mis hors de cause.
--
En esperant avoir fait avancé le sujet.
ted
mat
> Salut,
>
>
> Ton post semble vouloir être contructif, pourtant il y a pas mal
> d'incohérences et de points sombres que je me permets de relever.
>
Salut Ted,
J'espère bien que vous connaissez mieux votre produit que moi. J'aurais
pourtant préféré des points plus concrèts de votre part. P.ex.
impossible de reproduire le comportement chez nous, etc. Il me semble
que vous manquez des arguments objectifs.
Normal que vous n'aimez pas mon style, je n'aime pas le vôtre.
Il n'y a pourtant pas de réponse aux que
- Pourquoi ces ralentissements si d'autres produits ne les montrent pas?
- Pourquoi parler d'un problème générale de Windows si d'autres
produits ne le connaissent pas?
- Pourquoi dévier l'attention sur la vitesse en générale? Ceci n'est
pas ma préoccupation principale dans le contexte actuel, et vous le
savez très bien.
Par contre il y a toujours plus d'indications que le problème est
vraiment dû aux OpLocks et que vous n'avez pas de solution.
Salutations
Mat
> Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la
> version C/S. Il semble que tu possèdes des élements de test interressant.
> Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une
> ligne dans le code de l'application
Après mon expérience désastreuse avec WD7/7.5 je n'utiliserai plus aucun
nouveau produit PC Soft jusqu'il a été commercialisé pendant un certain
temps et qu'on entend plus parler de problèmes apparents. En plus, un
plus en vitesse n'est pas une assurance qu'il n'y aura pas le même
problème après modification de données.
>>Le Service Technique a réagit rapidement à notre communication la
>>semaine passée, mais il ne répète que le point de vue publié en
>>octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver
>>sous FAQ 2861).
>>identiques pour 2 ou 50 postes. Les performances sont alors similaires
>>aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell.
>>C'est le mécanisme de gestion du verrou opportuniste de Windows qui
>>implique cela."...
>
>
> Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres
> seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce
> document avec d'autres type de serveurs nous n'avons pas observé de
> changement brusque des perfomances au deuxième utilisateurs. Il y a donc
> pour nous bien un lien spécifiques avec les serveurs NT.
C'est justement ce que je critique: Windev est fait pour Windows et HF
n'est pas capable de gérer les requêtes d'une manière normale sous cet
OS. D'autres produits n'ont aucun problème avec des données résidant sur
NT/W2K Serveur.
>>ralentissement d'une requête est normal lorsqu’un des fichiers est en
>>modification sur un autre poste. Mais en chiffres ça veut dire quoi ?
>>Chez nous: Paradox + 16%
>>Access 2000 + 18%
>>Windev/HF + 270%
>
>
> Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit
> de base de données avec les mêmes structures ?
J'ai bien dit que les données des fichiers Windev et Paradox sont les
mêmes, (toutes les rubriques des commandes et lignes de commandes). Les
données Windev ont été importé de Paradox. Sous Paradox il y a 10% plus
d'enregistrements (4428 au lieu de 4041). On ne teste pas la rapidité de
la requête, on teste le plus de temps un requête a besoin sur des
fichiers modifiés par rapport à des fichiers sans modifications.
>
> dans notre société, nous avons également fait des tests.
> Nous avons obtenu des résultat très différents en fonction de la taille
> des enregistrements.
> La différence de vitesse se fait sentir pour les fichiers qui ont des
> enregistrements de petites tailles.
> Pour des fichiers avec de très gros enregistrements, il y a peu ou même
> pas de différence.
> Dans nos test la charnière se trouvait à unne taille d'enregistrement
> entre 250 et 300 octets.
> Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
Je ne comprends pas ce paragraphe. Si vous avez fait des tests, alors
montrez les résultats. Tous nos tests ont été fait sur les mêmes
machines, sans changement de configuration. La taille des
enregistrements (taille/nb enregistrements, sur fichier compacté),
commandes, suivi par lignes de commandes:
HF : 614 + 418 = 1032 octets, total 4041 enreg. dans le résultat
Paradox: 800 + 334 = 1134 octets, total 4428 ""
Encore une fois, même que je suis triste que les requêtes Windev sur HF
prennent plusieurs fois le temps d'autres produits, cela n'est pas en
cause: nous parlons du fait que des requêtes en lecture seule ne se
comportent pas comme des requêtes en lecture seule.
>>3) Windev cache les lenteurs de ses requêtes en les exécutant en
>>arrière plan.
>
>
> Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un
> confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres
> bases de données telle que Oracle par exemple.
> Dans une application tu préfères attendre 10 secondes sans ne pourvoir
> rien faire, ou avoir un début de résultat immédiatement avec la
> possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre
> la recherche pour lancer une autre recherche ?
C'est hors contexte et tu le sais: si je dois accéder p.ex. au dernier
enregistrement ou s'il y a une autre situation décrit dans mon post
d'origine, tu doit attendre de toute façon tes 10 secondes.
>>La recommandation de certains gens qu'un index composé des rubriques de
> trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
>>utilisés.
>
> C'est faux. Si tu as des indexes qui correspondent à tes critères et en
> plus des indexes qui correspondent a tes tris cela sera plus rapides.
> Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre
> des index sur toutes les rubriques. Il faut mettre les index sur les
> rubriques qui sont le plus souvent en critères, et surtout qui sont
> sucéptibles d'être les plus discréminentes.
Encore hors contexte. Je ne dis pas que les index ne servent à rien. Je
dis qu'ils n'aident pas à retrouver la vitesse lorsque on utilise des
clés de liaison entre deux fichiers: p.ex. en relie commandes et lignes
de commandes par l'ID. Aucun problème de faire un tri descendant sur
l'ID, le résultat est rapide. Mais le moment que tu tries sur la date,
qui a bien un index mais ne se trouve que dans un des deux fichiers,
alors la requête se ralentisse énormément. D'ailleurs c'est un autre
comportement que nous n'avons jamais vu avec d'autres produits. Le trie
de la requête ne ralenti pas les requête de la même façon que Windev.
Mais ça c'est aussi hors contexte actuellement.
>>4) Le plus déconcertant est la découverte qu'une requête exécutée sur
>>un poste client utilise un fichier temporaire sur le SERVEUR
>
>
> Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très
> affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il
> créé ?
> Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir
> paramétrer l'emplacement d'un tel fichier.
> Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
J'ai évidemment un problème de m'exprimer correctement. Avec un peu de
bonne volonté, et une reproduction chez soi en cas de doute, j'espère
qu'on arrive quand-même de comprendre mon message.
Il est pour moi secondaire s'il s'agit d'un fichier ou d'une table de
verrous ou de contrôle. Le fait est qu'une fois des fichiers ont été
modifiés en réseau, la gestion de ces fichiers lors d'accès ultérieurs
en lecture seule change. Un seul utilisateur, aucun problème, s'il y a
d'autres, et tous également en lecture seule, les temps d'accès
dégradent de nouveau. PLUS PERSONNE EST EN MODIFICATION! mais le
comportement comme si quelqu'un était en modification persiste.
La seule façon de rétablir la vitesse initiale de l'accès
multi-utilisateur en "lecture seule" est de redémarrer le serveur. De ce
fait le terme "fichier temporaire" sur le serveur.
Si vous me dites qu'il est impossible de reproduire ce comportement,
c'est une chose et probablement vous pourrez nous aider à trouver la
raison pourquoi c'est le cas chez nous.
Si vous dites que ce comportement est normal sous Windows Server, je ne
suis pas d'accord. Après les tests fait à ce jour, je pense je peux dire
tranquillement que c'est faux et si vous insistez sur ce point sans
fournir des preuves au contraire, je classe cetted declaration comme
mensonge.
>>5) Autre indice que les lenteurs de Windev / HF sont faits maison
>>plutôt que dû au réseau: si le ralentissement venait uniquement du
>>fait que le serveur doit interrompre le verrou OpLock, alors le retard
>>serait toujours le même dans le réseau. En réalité le ralentissement
>>en secondes dépend de la performance du PC client. Alors il s'agit
>>bien d'une question de traitement et ne pas de réseau!
>
>
> C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas
> C/S. Les perfomances dépendrons donc toujours AUSSI du poste client.
> C'est chaque poste client qui effectue ses propre recherches. Chaque
> poste client fait des lectures au poste sur lequel sont les fichiers. Les
> perfomances dépendant donc du poste serveur et des caches qu'il met à
> disposition, mais aussi de la rapidité avec laquelle les demandes sont
> effcetuées par le poste client.
> Shématiquement on peut facilment imaginer comment cela fonctionne :
> Les données sont lues sur le poste serveur et sont rappatriés sur le
> poste client. Si les caches sont activés, il peut y avoir plus de données
> que ce que le client a demandé, et le tout reste dans le cache du poste
> local. Selon la requête et les données déjà lues, le poste client va
> faire d'autres lectures sur le serveur (ici variaions possibles en
> fonction du poste client). S'il y a des élements dans le cache local et
> que les données à lire sont dans ce cache c'est autant de lecture
> "instantannées". Sans cache chaque nouvelle lecture représente un nouvel
> accès au réseau.
Merci pour ces explications. C'est une affirmation que les requêtes
Windev sur HF utilisent volontairement le système des OpLocks de Windows
lorsque il est disponible. C'est là la différence avec d'autres
produits. Je dirais qu'eux s'en fichent de OpLocks. Une requête exécuté
sur un poste est toujours envoyée au serveur qui ensuite toujours envoie
les données. Le poste ne prend jamais les données d'une requête
provenant du serveur du cache locale! Que ça se passe plus vite lorsque
une requête est exécuté plusieures fois sur le même poste, devrait être
dû au fait que le serveur trouve les même données dans son cache, mais
pas parce que le poste trouve les donnés dans son cache. Certes, il y a
bcp de chose que ne comprends pas, mais il ne faut pas être Einstein
pour comprendre cette situation.
Je répète que tous nos test ont été exécuté avec l'usage du cache réseau
et OpLocks activé sur le serveur (paramètres LanManServer) et désactivés
sur les postes (paramètres LanManWorkstation et Rdir).
Si vous dites que c'est le comportement normal sous les OS serveur de
Windows pour des requêtes en lecture seul, moi je dis que non, ce n'est
pas le comportement normal et celui d'autres produits sous les mêmes
conditions le prouvent.
En principe ça m'est égale comment sont gérée les requêtes, mais il faut
que c'est efficace, sans pénaliser l'utilisation multi-utilisateurs.
mat
J'ai malheureusement oublié de copier mon post sur de Windev-Forum du 22
septembre 23:49. Le voici:
mat wrote:
> CONSTATS
> --------
> ... 4) Le plus déconcertant est la découverte qu'une requête exécutée
sur un
> poste client utilise un fichier temporaire sur le SERVEUR, au lieu du
> disque local. C'est à notre avis la raison principale des
> ralentissements: c'est plus lent d'écrire sur le serveur que sur son
> disque local et en plus cela provoque des conflits lors d'un 2e accès
> car il doit gérer plusieurs contextes du "même fichier". On peut
> facilement vérifier ce comportement: on ouvre la même fenêtre avec une
> table alimentée par une requête EN LECTURE SEUL sur le Serveur et un
> poste client. On modifie sur le serveur un seul champ de la table et le
> temps de réponse de la requête sur le poste client passe IMMéDIATEMENT
> au mode "modification multi-utilisateur", donc + 270%, et ceci pour tout
> le monde. POURTANT IL N'Y A AUCUNE MODIFICATION DU FICHIER DE DONNÉES,
> AVEC UNE REQUÊTE EN LECTURE SEULE, UNIQUEMENT DANS LA TABLE, C'EST-A
> DIRE LA REQUETE SUR UN AUTRE PC.
>
Bonsoir,
J'ai été contacté par PC Soft parce qu'il ne comprennent pas le début du
paragraphe ci-dessus. Selon leurs ingénieurs c'est impossible qu'un
fichier temporaire est écrit sur le serveur.
En effet, il s'agit d'une déduction de ma part à partir de deux faits et
je m'excuse pour l'imprécision de ma formulation.
1) Pendant nos nombreux tests en 2003, nous avions aussi une
configuration avec les données sur un PC sous W98SE et un poste client
sous W2K Pro. Malheureusement j'ai perdu ce protocole. Lorsque la
fenêtre était déjà ouverte sous W98SE, l'ouverture sous W2K plantait (ou
à l'inverse), disant que le fichier "NomRequête" était verrouillé (sur
le "serveur"). Ceci nous faisait penser que la requête essaye d'utiliser
un fichier sur le serveur (pas nécessairement écrire). Il est bien
possible qu'il y ait une autre raison pour ce comportement, mais à
l'époque, nous avions reçu l'info du ST que dans certains cas Windev
n'obtenait pas la taille correcte du disque local et utilisait le disque
du serveur. Dans mon rapport du 2 juillet 2003 au STG j'ai communiqué
une impression que cette modification dans la table faisait déclencher
les OpLocks de Windows, chose qui ne se produit pas avec les BD d'autres
produits.
2) Également sous WD8, la modification d'une table fichier alimentée par
une requête en lecture seule ouverte sur le serveur réussit à ralentir
immédiatement l'exécution de la même requête sur les postes clients.
Ceci veut dire qu'il y a bien une interférence du serveur sur les
requêtes en lecture seule exécutés sur d'autres PC. Je répète, les
fichiers de données ne sont pas touchés, uniquement la table sur le
serveur, liée à une requête en lecture seule qui devrait normalement se
trouver uniquement en mémoire du poste en question, et probablement sous
forme de fichier sur le poste local...
Grâce à la patience de l'interlocutaire de PC Soft, car je dois avouer
que moi je commence occasionnellement de la perdre, je pense l'entretien
a quand-même été constructif. A la fin du compte leur observation m'a
fait remarquer la différence fondamentale entre les tables/grid des
autres producteurs et celles que j'utilise sous Windev. Les dernières
sont des tables fichier et les premières de "type table/grid mémoire",
mais seulement lorsqu'une requête est concerné.
Peut-être, le problème vient de la gestion de la table et ne pas de la
requête. Le résultat reste bien sûr le même, mais éventuellement ça
aidera à découvrir plus facilement la source de l'ennui. PC Soft
semblent prendre la chose au sérieux. Selon eux il n'y a pas de raison
que ces ralentissements devraient se produire, même avec une table fichier.
Mat
---------------------------------------------------------------------
Pour tout savoir sur windev-forum... Pour se désabonner...
Une seule adresse : http://www.teaser.fr/~edemeester/wdfaq.htm
mat
J'ai fait deux nouveaux séries de tests, cette fois incluant deux tables
mémoires, une fois avec la table permettant la saisie, une fois en
affichage seulement.
J'ai eu deux surprises avec la table fichier:
1) En modifiant la table fichier sur le serveur, je ne peux plus
reproduire le passage dans le ralentissement maximal comme la dernière
fois à plusieurs reprises.
2) Pour les nouveaux tests, le nombre d'enregistrements a été limité
avec un filtre SQL "AND DATE >= 20000101 ", donnant un résultat de 476
enregistrements. Après modification des fichiers sur un autre PC mon
poste client P1 passait "normalement" dans le ralentissement maximale et
affichait le nombre de lignes de la table, ainsi que le temps de 4.3
secondes. Régulièrement. Mais aussi régulièrement, il recevait encore
des données du serveur pendant 19-20 secondes. Ceci continuait même en
fermant la fenêtre et s'arrêtait seulement en quittant l'application.
Hier, j'ai fait une autre série de tests après recompilation du
projet et d'une nouvelle exe. Ce phénomène a disparu. Le transfert de
donnés s'arrête maintenant avec l'affichage des 476 enregistrements.
Table mémoire
-------------
J'ai d'abord essayé FichierVersTableMémoire. Sur les 4041
enregistrements le temps de chargement était de 11 secondes, en local.
Alors, j'ai abandonné cette fonction et selon recommandation de Rolf
Hentschel utilisé les commandes "manuels" pour remplir la table. Ceci
est le code dans l'initialisation de la fenêtre. J'ai trouve que c'était
un peu plus vite que de le faire dans les déclarations globales. Je n'ai
par contre pas trouvé de différence en mettant la table invisible, comme
j'ai lu quelque part, non plus dans les déclarations globales. Peut-être
ça dépend où se trouve le code.
Table..Visible = Faux
TableSupprimeTout(Table)
POUR TOUS sql_test SUR "IDContract"
TableAjouteLigne(Table,Rubrique1,Rubrique...,Rubrique10)
FIN
Table..Visible = Vrai
Info(Table..Occurrence,HeureDifférence(vStartTime,HeureSys))
Requête de sélection:
select * from Contract,ContractDetail
where ContractDetail.IDContract = Contract.IDContract
and Contract.Date >= '20000101'
Voici les résultats (partout 476 enregistrement dans le résultat, sauf
les premiers 2)
P2 lecture P2 écriture
Test P1 lecture P1 lecture P1 lecture
-----------------------------------------------------------
4041 enregistrements
Table fichier* 5.5 7.0 +27% 24.6 +347/+251% (22.9.)
Table fichier* 8.7 10.7+23% 41.0 +370/+283% (23.9.)?
476 enregistr. (1.2-1.4) (4.2-4.3)
Table fichier* 1.3 1.5 +15% 4.2 +223/+180%
Table mémoire (0.8-1) (0.8-1)
"Affich. seul." 0.9 0.9 2.5 +178%
Table mémoire 1.0 1.2 +20% 2.7 +170%/+125%
"saisie"
Paradox7 0.7 0.7 0.8 +14%
476 enreg.
(*) Pas de différence constaté entre table "saisie" et table en
"affichage seul".
Constats
--------
1) Le ralentissement avec le(s) fichier(s) en modification n'est pas
linéaire. La dégradation de performance en pourcentage pour les 476
enregistrements est moindre que celle des 4041 enr.
2) Ce n'est pas nécessaire que quelqu'un soit en modification/ajout pour
être pénalisé par le ralentissement. Il suffit que deux postes se
connectent avec une table en affichage/requête en lecture seule. La
seule façon que nous avons trouvé pour retrouver le temps d'affichage
correct est de redémarrer le serveur.
3) Les tables mémoires montrent le même phénomène, mais en moindre
mesure. En utilisant TableAjouteLigne, l'affichage d'une table mémoire
est plus rapide que celle d'une table fichier (-30%, ou bien table
fichier + 44%). Avec les fichiers en modification, table mémoire = -40%,
ou table fichier = + 68%.
4) Dans le cas de tables mémoires, il semble qu'une table en "mode
affichage seule" donne un léger avantage dans le temps d'affichage sur
une table permettant la saisie. Cette différence n'est pas du tout
apparente pour une table fichier.
5) Les résultats de la table fichier ont beaucoup varié d'un jour à
l'autre sans raison apparente. Peut-être parce que hier j'ai compilé le
projet avant chaque nouvelle création de l'exécutable afin d'éviter des
comportements étranges expérimentés avant-hier?
Les tests ont encore confirmé la forte dégradation de performance d'une
requête en lecture seule après les fichiers ont été modifiés. Ils
n'ont pas confirmés les soupçons mentionné avant-hier en ce qui concerne
la modification de la table sur le serveur. La chose qui reste est que
voulu ou pas, les requêtes de Windev sur HF sont influencés par les
OpLocks, tandis que d'autres produits ne le sont pas.
Mat
mat
mat wrote:
> Constats
> --------
> 2) Ce n'est pas nécessaire que quelqu'un soit en modification/ajout
> pour être pénalisé par le ralentissement. Il suffit que deux postes
se > connectent avec une table en affichage/requête en lecture seule. La
> seule façon que nous avons trouvé pour retrouver le temps d'affichage
> correct est de redémarrer le serveur.
svp lire:
1ère ligne: ...pas nécessaire que quelqu'un RESTE en modification/ajout
pour...
2e ligne: ... il suffit que deux AUTRES postes se connectent...
ted
Salut,
>
> J'espère bien que vous connaissez mieux votre produit que moi.
Désolés mais ce n'est pas mon produit, même si j'aimerai bien. Je suis un
utilisateur content et qui aime défendre son outil de développement car
c'est aussi son gagne pain.
> J'aurais pourtant préféré des points plus concrèts de votre part.
> P.ex. impossible de reproduire le comportement chez nous, etc.
Je n'ai jamais dit cela. Ce que je dit c'est que nos tests ne montrent
pas exactement la même chose que les tiens. Et que les résultats varient
en fonctions de la taille des rubriques.
> Il n'y a pourtant pas de réponse aux que
> - Pourquoi ces ralentissements si d'autres produits ne les montrent
> pas? - Pourquoi parler d'un problème générale de Windows si d'autres
> produits ne le connaissent pas?
j'aimerai conaitre la réponse, et je pense que Pcsoft aussi.
Car nous constatons nous ausi un ralentissement, mais celui-ci permet
quand même une utilisation normal de l'application.
>
> Par contre il y a toujours plus d'indications que le problème est
> vraiment dû aux OpLocks et que vous n'avez pas de solution.
>
Mon but est d'apporté le maximum d'indications aux autres développeurs
(et à Pcsoft) de façon a ce que chacun puisse avoir des applications les
plus perfomantes possibles.
Je n'ai effectivement pas de solution, pas plus que toi d'ailleur.
> Après mon expérience désastreuse avec WD7/7.5 je n'utiliserai plus
> aucun nouveau produit PC Soft jusqu'il a été commercialisé pendant un
> certain temps et qu'on entend plus parler de problèmes apparents. En
> plus, un plus en vitesse n'est pas une assurance qu'il n'y aura pas le
> même problème après modification de données.
C'est un choix. Mais la personne ne te demande pas d'acheter un maj pour
commercialiser ton application avec. Nous sommes plusieurs à te dire
qu'il est possible de faire un test avec une version gratuite. Ce test
pourrait te rassurer et rassurer d'autres développeurs. Moi le premier,
si tu me dis que tu continues à avoir des pb je ne serai pas rassuré,
mais si tu dis que tu n'as plus de pb cela me rassurera.
Nos tests nous ont montré un plus de vitesse comme tu dis, mais nous ont
aussi montré que le problème après modification des données n'est plus
présent. La version C/S permet de faire des modification et de tester
cette configuration !
> en cause: nous parlons du fait que des requêtes en lecture seule ne se
> comportent pas comme des requêtes en lecture seule.
>
> dégradent de nouveau. PLUS PERSONNE EST EN MODIFICATION! mais le
> comportement comme si quelqu'un était en modification persiste.
>
> La seule façon de rétablir la vitesse initiale de l'accès
> multi-utilisateur en "lecture seule" est de redémarrer le serveur. De
> ce fait le terme "fichier temporaire" sur le serveur.
Non, pour rétablir la vitesse lié au mécanisme OpsLock, il faut que tous
les processus qui ont ouvert le fichier le referme. C'est ce que j'ai
constaté et ce que Microsoft docummente :
http://msdn.microsoft.com/library/en-
us/fileio/base/opportunistic_locks.asp
>
> Si vous dites que ce comportement est normal sous Windows Server, je
> ne suis pas d'accord. Après les tests fait à ce jour, je pense je peux
> dire tranquillement que c'est faux et si vous insistez sur ce point
> sans fournir des preuves au contraire, je classe cetted declaration
> comme mensonge.
Et pourtant je le prouve.
Je ne sais pas ce qui est utilisé dans Hyper File. Mais ci-dessous je
donne un code W-Langag qui utilise les fonctions de base de l'API pour la
gestions des fichiers. Ce code permet de reproduire le phénomène.
Ceux qui veulent le convertir dans un autre lanage peuvent le faire,
c'est sans rapport avec le langage.
Ce code permet au chois de faire une lecture sur un fichier ou de faire
un petit blocage sur un fichier. Pour utiliser ce code et mettre le
phénomène en évidence, il faut l'exécuter comme suit :
- Test mono-utilisation
Sur un poste faire une lecture en étant seul sur le fichier
- Test multi-utilisation
Sur un poste faire un blocage d'un octet du fichier
Sur l'autre poste faire une lecture du même fichier.
//Variable pour chronomtrage
sHeureDebut,sHeureFin sont des DateHeures
//Compteur du nombre de lecture
eNbLectures est un entier
//Handle du fichier manipul
eHandleFichier est un entier
//Nom du fichier manipul
sNomFichier est une chane
//Type d'ouverture du fichier (L/E)
eTypeOuverture est un entier
//Constantes Windows pour le type d'ouverture
GENERIC_READ est un entier=(0x80000000)
GENERIC_WRITE est un entier=(0x40000000)
//Type de partage du fichier
eTypePartage est un entier
//Constantes Windows pour le type de partage
FILE_SHARE_READ est un entier=(0x00000001)
FILE_SHARE_WRITE est un entier=(0x00000002)
//pointeur sur une structure pour les process qui hrite de ce handle.
NULL car pas d'autres process.
eSecuriteNonUtilse est un entier=Null
//Mthode de cration / d'ouverture (similaire HCration ou
HCreationSiInexistant ou HOuvre...)
eTypeCreation est un entier
//Constantes Windows pour le type de cration
CREATE_NEW est un entier=1
CREATE_ALWAYS est un entier=2
OPEN_EXISTING est un entier=3
OPEN_ALWAYS est un entier=4
TRUNCATE_EXISTING est un entier=5
//Paramtres du cache systeme
eAttributsCache est un entier
//Constantes Windows pour les ttributs et le cache system
FILE_ATTRIBUTE_READONLY est un entier=0x00000001
FILE_ATTRIBUTE_HIDDEN est un entier=0x00000002
FILE_ATTRIBUTE_SYSTEM est un entier=0x00000004
FILE_ATTRIBUTE_DIRECTORY est un entier=0x00000010
FILE_ATTRIBUTE_ARCHIVE est un entier=0x00000020
FILE_ATTRIBUTE_NORMAL est un entier=0x00000080
FILE_ATTRIBUTE_TEMPORARY est un entier=0x00000100
//Type d'accs
//Accs de type "alatoire"
FILE_FLAG_RANDOM_ACCESS est un entier=0x10000000
//Accs de type squentiel
FILE_FLAG_SEQUENTIAL_SCAN est un entier=0x08000000
//Constantes non dispo sus 95/98/Me :
FILE_FLAG_BACKUP_SEMANTICS est un entier=0x02000000
//Constantes concernant les caches
//Pour ne pas utiliser les caches systemes
FILE_FLAG_NO_BUFFERING est un entier=0x20000000 //Ecriture
directe sans les caches system
//Attention dans ce cas il faut faire les lecture par un multiple de la
taille d'un secteur (GetDiskFreeSpace pour aavoir la taille d'un secteur)
FILE_FLAG_OVERLAPPED est un entier=0x40000000 //traitement
asynchrone de L/E
FILE_FLAG_WRITE_THROUGH est un entier=0x80000000 //Ecrit dans les
cache et flush les caches
//Constantes Handle invalide
INVALID_HANDLE_VALUE est un entier=-1
//Template : Non support sous 95/98/Me
hTemplateFile est un entier=Null
//Pour la lecture
sChaineLue est une chane
eNbOctetsUnEnreg est un entier
eNbOctetsLus est un entier
lpOverlapped est un entier=Null //Pour les L/E asynchrone
//Contante Windows pour le positionement dans le fichier
FILE_BEGIN est un entier=0
FILE_CURRENT est un entier=1
FILE_END est un entier=2
//Pour la rcupration des informations sur le disque destination (Fonction
de l'API "GetDiskFreeSpace")
eNbSecteursParCluster est un entier
eNbOctetsParSecteur est un entier
eNbClustersLibres est un entier
eNbTotalDeClusters est un entier
//********************** Pour 'API <LockFileEx> :
LOCKFILE_EXCLUSIVE_LOCK est un entier=2
LOCKFILE_FAIL_IMMEDIATELY est un entier=1
eTypeBlocage est un entier=LOCKFILE_FAIL_IMMEDIATELY
eReserv est un entier=0
ePartieBasseNbOctetsaBloquer est un entier=1
ePartieHauteNbOctetsaBloquer est un entier=0
StrOVERLAPPED est un compose de
Internal est un entier=0
InternalHigh est un entier=0
ePartieBassePositionFichier est un entier=1
ePartieHautePositionFichier est un entier=0
hEvent est un entier=0
FIN
//**********************
bLecture est un boolen
ePosRes est un entier
eNbMaxLecture est un entier
//Fichier manipuler
sNomFichier=fSlecteur("", "", "Sélectionnez un fichier...", "Tous
fichiers (*.*)"+TAB+"*.*"+RC+"Hyper File (*.fic)"+TAB+"*.FIC", "FIC",
fselOuvre+fselExiste)
//fichier sélectionné ?
SI sNomFichier="" ALORS
RETOUR
FIN
//---Avec une fenêtre qui contient un super champ de sélection de fichier
on peut mettre
//sNomFichier=SCSelecteurFichier.SAIS_FIC
eNbOctetsUnEnreg=100// Taille d'un enregistrement
//---Avec une fentre qui contient un champ de saisie on peut mettre :
//eNbOctetsUnEnreg=CHPTAILLEENREG// Taille d'un enregistrement
bLecture=OuiNon("Que voulez-vous faire ? "+RC+"- Lire le fichier :
OUI"+RC+"- Ouvrir et bloquer une partie du fichier : NON (dans ce cas une
fenêtre Info conserve le fichier bloqué pour permettre le lancement d'un
test de lecture depuis un autre poste)")
eNbMaxLecture=10000
//---Avec une fentre qui contient un champ de saisie on peut mettre :
//eNbMaxLecture=CHPNBMAXLECTURE
//---- Paramtres d'ouverture du fichier
//Ouverture en L/E
eTypeOuverture=GENERIC_READ+GENERIC_WRITE
//Partage en L/E
eTypePartage=FILE_SHARE_WRITE+FILE_SHARE_READ
eSecuriteNonUtilse=Null //pas utilisé
//Ouvre si le fichier existe dj
eTypeCreation=OPEN_EXISTING
//Accès en attribut normal, accès "alatoire" (une lecture "classique" est
ordonnées sur l'index mais pas sur les données)
eAttributsCache=FILE_ATTRIBUTE_NORMAL+FILE_FLAG_RANDOM_ACCESS
//Ouverture du fichier
eHandleFichier=AppelDLL32("KERNEL32","CreateFileA",&sNomFichier,...
eTypeOuverture,eTypePartage,eSecuriteNonUtilse,eTypeCreation,eAttrib
utsCache,hTemplateFile)
//Fichier bien ouvert ?
SI eHandleFichier=INVALID_HANDLE_VALUE ALORS
Erreur("Erreur d'ouverture du fichier",ErreurInfo())
RETOUR
FIN
//Lecture
SI bLecture ALORS
//On met la taille la chaine qui va "rcptionner" les valeurs lues
sChaineLue=Complte("",eNbOctetsUnEnreg)
BoucleParcours : //Label pour GOTO
//RAZ compteur du nombre de lectures
eNbLectures=0
//Début Chrono
sHeureDebut=DateSys()+HeureSys()
BOUCLE
//Lecture d'un enregistrement
SI PAS AppelDLL32("KERNEL32","ReadFile",eHandleFichier,
&sChaineLue,eNbOctetsUnEnreg,&eNbOctetsLus,lpOverlapped) ALORS
Erreur("Erreur de lecture",ErreurInfo())
SORTIR
FIN
//Fin de fichier ?
SI eNbOctetsLus=0 ALORS SORTIR //fin de fichier
//Enregistrement suivant
eNbLectures++
SI eNbLectures=eNbMaxLecture ALORS SORTIR
FIN
//Fin Chrono
sHeureFin=DateSys()+HeureSys()
//Affichage du rsultat
//La fermeture du fichier ne se fera qu'aprés validation afin de
pouvoir faire un test en parallèle sur un autre poste avant la fermeture
du fichier
SI OuiNon(eNbLectures+" lectures en "+DuréeVersChane(sHeureFin-
sHeureDebut,"J.HH:MM'SS''LLL"),"Recommencer ? Sinon fermeture du
fichier.") ALORS
//on se repositionne au début du fichier
API
("KERNEL32","SetFilePointer",eHandleFichier,0,Null,FILE_BEGIN)
//on recommence
GOTO BoucleParcours
FIN
SINON
//Blocage
//Lecture d'un octet
sChaineLue=" "
eNbOctetsUnEnreg=1
SI PAS AppelDLL32("KERNEL32","ReadFile",eHandleFichier,
&sChaineLue,eNbOctetsUnEnreg,&eNbOctetsLus,lpOverlapped) ALORS
Erreur("Erreur de lecture",ErreurInfo())
SINON
//on bloc en écriture : eTypeBlocage=0
SI PAS API
("KERNEL32","LockFileEx",eHandleFichier,eTypeBlocage,eReserv,ePartieBasse
NbOctetsaBloquer,ePartieHauteNbOctetsaBloquer,&StrOVERLAPPED) ALORS
Erreur("Erreur de blocage",ErreurInfo())
SINON
Info("Fichier bloqué. Lancez un test de lecture depuis un
autre poste. Une fois le test terminé cliquez sur OK pour femer le
fichier.")
FIN
FIN
FIN
//Fermeture du fichier
SI PAS AppelDLL32("KERNEL32","CloseHandle",eHandleFichier) ALORS
Erreur("Pb de fermeture du fichier",ErreurInfo())
FIN
--
En esperant avoir fait avancé tout le monde.
ted
mat
J'ai également visité le KB de MS et trouvé des informations similaires.
Peut-être on avancera un peu.
Voici encore ce que je trouve bizarre.
1) Est-ce qu'il s'agit vraiment d'un problème OpLocks ou pas? Il est
confirmé dans la doc Microsoft que les OpLocks sont toujours
demandé du client ou d'une application. Pour des raisons de sécurité
beaucoup de gens recommandent depuis longtemps de désactiver les OpLocks
et le Cache Réseau sur les postes accédant des serveurs NT/W2K. Nous
avons donc cette situation et de notre coté, les postes clients ne
demandent pas les OpLocks. Voici les paramètres du poste P1 utilisé dans
lest tests:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters]
"enableplaintextpassword"=dword:00000000
"enablesecuritysignature"=dword:00000001
"requiresecuritysignature"=dword:00000000
"OtherDomains"=hex(7):00,00
"UtilizeNtCaching"=dword:00000000
"UseOpportunisticLocking"=dword:00000000
Mais de toute façon, le poste ne peut pas ouvrir les fichiers HF sans
intervention du DLL HF, alors c'est là où le type d'accès est défini.
2) J'ai souvent compilé le projet et tout à coup il m'a donné un warning
sur une variable locale dans une fonction qui cache une variable globale
de la fenêtre. Ce code date du 15/9 et la variable globale du 4/9 et
jamais reçu ce message auparavant.
Autre effet: après des tests rapides avec hFerme("") et mettre/ne pas
mettre HAnnuleDéclaration, la rapidité de la requête fichier a tout à
coup été amélioré notablement. Le comportement est toujours le même,
mais la vitesse maintenant égale à celle de la table mémoire: ~0.9 sec
en lecture mono-poste, ~1.0 sec en lecture multiposte, ~2.5 sec en
lecture sur P1 avec modif sur P2.
L'essai de provoquer de nouveau un ralentissement n'apporte rien. Après
plusieurs compilations, les temps d'exécution restent le même. N'importe
s'il y a hFerme("") ou HAnnuleDéclaration pour la requête sur le poste
qui fait la modif dans le fichier (directement dans le fichier, pas à
travers la requête, qui est d'ailleurs pas la même que celle lu sur
l'autre poste, mais utilise les mêmes fichiers.)
Est-ce que l'éditeur de code ne traite pas toujours toutes les lignes de
code et quelques vieux bouts de code restent inchangés?
ted wrote:
>> La seule façon de rétablir la vitesse initiale de l'accès
>> multi-utilisateur en "lecture seule" est de redémarrer le serveur.
>> De ce fait le terme "fichier temporaire" sur le serveur.
>
>
> Non, pour rétablir la vitesse lié au mécanisme OpsLock, il faut que
> tous les processus qui ont ouvert le fichier le referme. C'est ce que
> j'ai constaté et ce que Microsoft docummente :
Alors là tu affirme que le problème vient des OpLocks? Donc il y a des
cas où HF utilise les OpLocks?
Je confirme que la fermêture des fenêtres, et même de l'application, ne
retablissent pas la vitesse d'origine. Le moment qu'un des postes
re-ouvre l'application et accède la même fenêtre en lecture seule ça va
normalement, mais un 2e utilisateur sera de nouveau rallenti.
Je précise que notre application ne ferme jamais exlicitement les
fichiers. Selon la doc de Windev, les fichiers sont géres
automatiquement. Si la fermeture explicite puisse aider, merci de m'en
informer. Les tests fait rapidement n'ont pas montré de différence.
>> Si vous dites que ce comportement est normal sous Windows Server,
>> je ne suis pas d'accord. Après les tests fait à ce jour, je pense
>> je peux dire tranquillement que c'est faux et si vous insistez sur
>> ce point sans fournir des preuves au contraire, je classe cetted
>> declaration comme mensonge.
>
>
> Et pourtant je le prouve. Je ne sais pas ce qui est utilisé dans
> Hyper File. Mais ci-dessous je donne un code W-Langag qui utilise les
> fonctions de base de l'API pour la gestions des fichiers. Ce code
> permet de reproduire le phénomène. Ceux qui veulent le convertir dans
> un autre lanage peuvent le faire, c'est sans rapport avec le langage.
>
>
> Ce code permet au chois de faire une lecture sur un fichier ou de
> faire un petit blocage sur un fichier. Pour utiliser ce code et
> mettre le phénomène en évidence, il faut l'exécuter comme suit : -
> Test mono-utilisation Sur un poste faire une lecture en étant seul
> sur le fichier
>
> - Test multi-utilisation Sur un poste faire un blocage d'un octet du
> fichier Sur l'autre poste faire une lecture du même fichier.
>
Avec preuve du contraire je pensais p.ex. de prouver que les autres
gestions de base de données avec "file share" se comporte de la même
façon que Windev. Si c'était le cas on pourrait dire que c'est un
phénomène général.
Je regrette, je ne comprends pas le but de ta démo. Je n'ai pas
d'expérience en programmation proche d'un OS. Tout de même,
> FILE_FLAG_OVERLAPPED est un entier=0x40000000
> //traitement asynchrone de L/E
est déclaré, mais pas utilisé dans le code en question. Si j'ai compris
correctement la doc de Microsoft, l'usage de OpLocks ne devrait alors
pas être possible.
D'autre part
> //Ouverture en L/E
> eTypeOuverture=GENERIC_READ+GENERIC_WRITE
me surprend. Depuis longtemps je dis que les requêtes "en lecture seule"
ne se comporte pas comme des "requêtes en lecture seul".
Est-il stupide de demander pourquoi on devrait ouvrir les fichiers d'une
requête SELECT en lecture et écriture?
Comme j'ai dit, j'y comprends rien, ais j'aurais pensé qu'une ouverture
de fichier pour une requête sans paramètre hModifieFichier utiliserait
quelque chose comme:
eTypeOuverture = GENERIC_READ
eAttributsCache = FILE_ATTRIBUTE_READONLY + FILE_FLAG_RANDOM_ACCESS
Et si le code ne correspondait pas à l'ouverture des fichiers d'une
requête SELECT, utilisé p.ex. par Windev, alors quel est le but de ce
test, stp?
Salutations
Mat
ted
Salut,
> 2) J'ai souvent compilé le projet et tout à coup il m'a donné un
Pas de rapport avec le sujet en cours.
> Je précise que notre application ne ferme jamais exlicitement les
> fichiers. Selon la doc de Windev, les fichiers sont géres
> automatiquement. Si la fermeture explicite puisse aider, merci de m'en
> informer. Les tests fait rapidement n'ont pas montré de différence.
Effectivement pour rétablir lee Opslocks il faudrait que tous les postes
ferme le/les fichiers sur lesqueles il y a eu modif ou blocage.
>> FILE_FLAG_OVERLAPPED est un entier=0x40000000
>> //traitement asynchrone de L/E
>
> est déclaré, mais pas utilisé dans le code en question. Si j'ai
> compris correctement la doc de Microsoft, l'usage de OpLocks ne
> devrait alors pas être possible.
D'après ce que j'ai compris/testé dés que tu manipules un fichier sur un
serveur NT/2000, l'utilisation des OpsLocks est automatiquement faite par
le system.
Les quelques tests que j'ai fait avec FILE_FLAG_OVERLAPPED montre que ce
paramètre n'est pas utilisable si on veut lires des données à jour.
Je ne peux maintenant pas t'assurer que les paramètres de mon code sont
ceux utilisés par Hyperfile, mais ils permettent de reproduir le même
phénomène.
As-tu fait un test de ce code ? N'as tu pas constaté les mêmes
différences de performance qu'avec Hyperfile ?
> D'autre part
>> //Ouverture en L/E
>> eTypeOuverture=GENERIC_READ+GENERIC_WRITE
>
> me surprend. Depuis longtemps je dis que les requêtes "en lecture
> seule" ne se comporte pas comme des "requêtes en lecture seul".
J'ai utilisé ces paramètre car dans mes appli en général je fit des
modif, et le pense que les requêtes ne re-ouvre pas les fichiers.
Maintenant tu peux mettre : eTypeOuverture=GENERIC_READ dans le cas de la
lecture (mais laisse eTypeOuverture=GENERIC_READ+GENERIC_WRITE pour le
lancement sur le poste qui bloque). A priori cela ne provoque pas de
différence.
> Comme j'ai dit, j'y comprends rien, ais j'aurais pensé qu'une
> ouverture de fichier pour une requête sans paramètre hModifieFichier
> utiliserait quelque chose comme:
> eTypeOuverture = GENERIC_READ
> eAttributsCache = FILE_ATTRIBUTE_READONLY + FILE_FLAG_RANDOM_ACCESS
>
> Et si le code ne correspondait pas à l'ouverture des fichiers d'une
> requête SELECT, utilisé p.ex. par Windev, alors quel est le but de ce
> test, stp?
Le but de ce test et de montrer que l'on peut obtenir ce même
ralentissement sans Hyperfile, avec quelques fonctions de base de l'API
de gestion des fichiers.
Si tu veux, tu peux faire des essais, et faire varier les différentes
constantes et différents paramètres. Si tu trouves une combinaison de
paramètres qui ne provoque pas de ralentissement dés qu'un second poste
fait des blocages/modif tient moi au courant, je contrete test et on fait
remonter à l'éditeur.
--
En esperant avancé toujours un peu plus.
ted
mat
>>Je précise que notre application ne ferme jamais exlicitement les
>>fichiers. Selon la doc de Windev, les fichiers sont géres
>>automatiquement. Si la fermeture explicite puisse aider, merci de m'en
>>informer. Les tests fait rapidement n'ont pas montré de différence.
>
>
> Effectivement pour rétablir lee Opslocks il faudrait que tous les postes
> ferme le/les fichiers sur lesqueles il y a eu modif ou blocage.
Manque de précision de ma part. Pour les tests, j'ai ajouté HFerme dans
toutes les fenêtres utilisés. Pourtant, la fermeture des fenêtres, ou
même de l'application, ne sont pas suffisants.
>>D'autre part
>>
>>>//Ouverture en L/E
>>>eTypeOuverture=GENERIC_READ+GENERIC_WRITE
>>
>>me surprend. Depuis longtemps je dis que les requêtes "en lecture
>>seule" ne se comporte pas comme des "requêtes en lecture seul".
>
>
> J'ai utilisé ces paramètre car dans mes appli en général je fit des
> modif, et le pense que les requêtes ne re-ouvre pas les fichiers.
> Maintenant tu peux mettre : eTypeOuverture=GENERIC_READ dans le cas de la
> lecture (mais laisse eTypeOuverture=GENERIC_READ+GENERIC_WRITE pour le
> lancement sur le poste qui bloque). A priori cela ne provoque pas de
> différence.
N'ayant pas d'expérience dans ce domaine, j'ai fait fausse route.
Revenant sur le principe de base: Pour autant que je sache, une requête
traditionelle exécuté sur un poste demande le fichier du serveur et
ensuite le traite en local. Ce type de conflit n'existe alors pas,
puisque la lecture est en local.
Le comportement décrit dans ton test correspond justement à quelque
chose que tu disait n'existait pas dans le cas d'une requête Windev sur
HF: l'usage d'un fichier sur le serveur.
J'espère que c'est plus précis et compréhensible cette fois.
Salutations
Mat
ted
@news.bluewin.ch:
Salut,
Je suis surpris de tes remarques qui me semblent beaucoup moins
judicieuses que les précédentes...
> Revenant sur le principe de base: Pour autant que je sache, une requˆte
> traditionelle ex‚cut‚ sur un poste demande le fichier du serveur et
> ensuite le traite en local. Ce type de conflit n'existe alors pas,
> puisque la lecture est en local.
J'espère bien que le fichier n'est pas récupéré en local sur le poste de
chaque client pour l'exécution de chaque requête !
Imagine une requête qui porte sur 3 fichiers, avec chacun 200.000
enregistrements. Avec cette technique il faudrait avoir des postes
clients avec +++ mémoire et +++ de place disque.
De plus durant le temps de 'copie' des fichiers en local des modif
pourraient être faites sur les fichiers...
Image aussi une requête dont le résultat est 1 enreg. Selon toi, dans ce
cas là aussi, il faudrait récupérer tout les fichiers en local ?
> Le comportement d‚crit dans ton test correspond justement … quelque
> chose que tu disait n'existait pas dans le cas d'une requˆte Windev sur
> HF: l'usage d'un fichier sur le serveur.
Ce que j'ai décrit c'est l'utilisation d'un fichier partagé en réseau.
J'espère que Hyperfile utilise directements les données des fichiers en
réseau, et cela en même temps depuis les différents postes clients. Par
contre ce que je n'espère pas c'est que Hyperfile cré un fichier
temporaire sur le serveur durant l'exécution. Suite à ton poste, j'ai
d'ailleur demandé confirmation à l'éditeur qui m'a confirmé ne pas
utiliser de fichier temporaire sur le serveur (ni sur le poste local).
--
En esperant t'avoir aidé.
ted
mat
>>Revenant sur le principe de base: Pour autant que je sache, une requˆte
>>traditionelle ex‚cut‚ sur un poste demande le fichier du serveur et
>>ensuite le traite en local. Ce type de conflit n'existe alors pas,
>>puisque la lecture est en local.
>
>
> J'espère bien que le fichier n'est pas récupéré en local sur le poste de
> chaque client pour l'exécution de chaque requête !
> Imagine une requête qui porte sur 3 fichiers, avec chacun 200.000
> enregistrements. Avec cette technique il faudrait avoir des postes
> clients avec +++ mémoire et +++ de place disque.
> De plus durant le temps de 'copie' des fichiers en local des modif
> pourraient être faites sur les fichiers...
> Image aussi une requête dont le résultat est 1 enreg. Selon toi, dans ce
> cas là aussi, il faudrait récupérer tout les fichiers en local ?
>
Bonjour Ted,
Il me semble que le seul but de tes posts est d'invalider mes
observations au lieu de les prendre pour ce qu'elles sont: des pistes
pour trouver la source du problème. Ce que tu dis ci-haut est n'importe
quoi.
Je n'ai aucune idée comment une requête fonctionne chez Visual Foxpro,
Access et Paradox, mais je sais qu'elles n'ont pas la lenteur des
requêtes de Windev sur HF après modifications de données. Je pense la
discussion a montré que vous êtes au courant de ces ralentissements et
n'avez pas de solution. Peut-être devriez vous ouvrir un peu l'esprit et
ne pas nier à priori les observations et l'expérience des autres?
Ci-bas un extrait de l'aide en ligne de Paradox 7 expliquant les
requêtes. Dans le cas de SQL server elles sont exécutés sur le serveur
et autrement en local. Si vous n'êtes pas au courant comment les
requêtes fonctionnent normalement avec un produit autre que Windev, je
ne peux rien pour vous.
Que tu trouves ça génial ou pas, les requêtes Paradox sont moyennement
bien plus vite que Windev sur HF, sans exécution en arrière plan. De la
situation après modification des fichiers des données on parle même pas.
Mais puisqu'on y est déjà: avec Paradox on peut également: définir le
nom du fichier temporaire contenant le résultat, définir le répertoire
où se trouve ce fichier, renommer le fichier par défaut "Answer.db" et
on a un fichier physique réutilisable, pour des listes, requêtes
enchaînées, archives, etc. Des choses dont un utilisateur Windev ne peut
que rêver pour l'instant. Et tout cela dans un temps époustouflant.
Pourtant, le but de mon post n'a jamais été pour dire qu'un produit est
mieux qu'un autre, mais que d'autres produits ne montrent pas ce
phénomène extrêmement gênant des requêtes Windev sur HF. C'est ma faute
si je ne sais pas m'exprimer mieux ou me suis laissé entraîner dans une
discussion apparemment inutile. Encore du temps perdu mais ce n'est pas
nouveau avec Windev et surtout PC Soft.
Salutations
Mat
AIDE EN LIGNE DE PARADOX 7
--------------------------
Queries Against Remote Tables
These options apply only to queries of remote data on SQL servers.
Running queries locally is slower, but might be necessary
for example, if you're querying joined tables from more than one server.
Query May Be Local Or Remote
Choose this button to make Paradox attempt to run the query remotely (as
described below). If this fails, Paradox runs the query locally (as
described below).
Run Query Remotely
Choose this button to make Paradox request that the server run the query
and send back only the answer data.
Run Query Locally
Choose this button to make Paradox run the query locally. This means
that Paradox
1. Requests all data in queried tables from the server.
2. Runs the query on your computer system.
Phil
news:41593...@news.bluewin.ch...
> Que tu trouves ça génial ou pas, les requêtes Paradox sont moyennement
> bien plus vite que Windev sur HF, sans exécution en arrière plan. De la
> situation après modification des fichiers des données on parle même pas.
> Mais puisqu'on y est déjà: avec Paradox on peut également: définir le
> nom du fichier temporaire contenant le résultat, définir le répertoire
> où se trouve ce fichier, renommer le fichier par défaut "Answer.db" et
> on a un fichier physique réutilisable, pour des listes, requêtes
> enchaînées, archives, etc. Des choses dont un utilisateur Windev ne peut
> que rêver pour l'instant. Et tout cela dans un temps époustouflant.
Bonjour Mat,
Malheureusement rien n'est parfait en ce bas monde. L'environnement de
développement Windev est fabuleux et exceptionnel, mais son talon d'Achille
est la vitesse des requêtes. Mais je garde espoir parce que je vois une
amélioration constante du produit.
Comme vétéran des produits FoxPro, je me rappelle que la première version
qui a intégré le SQL était tellement lente que j'ai revendu à rabais cette
version de FoxPro en moins d'une semaine. Mais cela n'a pas duré très
longtemps, à partir de la version suivante - la technologie Rushmore
aidant - tout était d'une vitesse fulgurante.
Comme tu dis, la création de fichiers temporaires physiques réutilisable par
un SQL est épatant. Pour travailler des requêtes complexes, il suffit de
décortiquer en plusieurs fichiers temporaires très facile à créer et à
manipuler. De plus, dès qu'on ferme un fichier temporaire, il s'efface
automatiquement du disque dur.
Je ferai face aux même problèmes que toi concernant la vitesse HF et des
requêtes d'ici quelques semaines. Heureusement, la version 9 est à l'horizon
avec sa vitesse C/S améliorée. Si je regarde l'évolution de Windev ces
dernières années, je fais le paris que PCS va éventuellement trouver
l'astuce qui va rejoindre les vitesses de FoxPro, Paradox et de ses
semblables. Entre-temps, je crois bien que la solution est de trouver des
astuces, jouer sur les (gros) index et placer des messages et des jauges
pour faire patienter le client.
Réal Philippon (Phil)