Daniel wrote:
> Concernant HF, j'ai de sérieux doute sur la solidité de cette base
> voyant les différents threads sur le sujet pour perte de donnée, in dex
> corrompus, etc...
...
Ca, ce n'est pas un problème HF, mais Windows, due à la configuration
réseau avec OpLocks et caches réseau activés par défaut dans les
versions depuis NT/W2K. Lorsqu'on prend les précautions, aucun souci
avec la stabilité de bases éprouvés, Access, VFoxpro, Paradox, HF ou
autre. Ce n'est pas que SQLServer, mySQL, Oracle sont vraiment plus
stables. Simplement leur architecture fait que c'est toujours 1 seul
ordi qui l'utilise (le serveur). C'est évidemment plus simple à gér er
par l'OS.
Daniel wrote:
> Concernant HF, j'ai de sérieux doute sur la solidité de cette base
> voyant les différents threads sur le sujet pour perte de donnée, in dex
> corrompus, etc...
...
Ca, ce n'est pas un problème HF, mais Windows, due à la configuration
réseau avec OpLocks et caches réseau activés par défaut dans les
versions depuis NT/W2K. Lorsqu'on prend les précautions, aucun souci
avec la stabilité de bases éprouvés, Access, VFoxpro, Paradox, HF ou
autre. Ce n'est pas que SQLServer, mySQL, Oracle sont vraiment plus
stables. Simplement leur architecture fait que c'est toujours 1 seul
ordi qui l'utilise (le serveur). C'est évidemment plus simple à gér er
par l'OS.
Daniel wrote:
> Concernant HF, j'ai de sérieux doute sur la solidité de cette base
> voyant les différents threads sur le sujet pour perte de donnée, in dex
> corrompus, etc...
...
Ca, ce n'est pas un problème HF, mais Windows, due à la configuration
réseau avec OpLocks et caches réseau activés par défaut dans les
versions depuis NT/W2K. Lorsqu'on prend les précautions, aucun souci
avec la stabilité de bases éprouvés, Access, VFoxpro, Paradox, HF ou
autre. Ce n'est pas que SQLServer, mySQL, Oracle sont vraiment plus
stables. Simplement leur architecture fait que c'est toujours 1 seul
ordi qui l'utilise (le serveur). C'est évidemment plus simple à gér er
par l'OS.
J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données. C'est clairement l'accès fichier choisi
par PC Soft qui est en cause puisque inexistant avec d'autre produits,
tels que Visual Foxpro ou Paradox. En fait, je n'ai pas apprécié du tout
que PC Soft ont fait tout pour mettre la responsabilité dans le coin de
Windows, plutôt que de résoudre le problème. De même avec les
difficultés avec les requêtes HF sur des fichiers partagés.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données. C'est clairement l'accès fichier choisi
par PC Soft qui est en cause puisque inexistant avec d'autre produits,
tels que Visual Foxpro ou Paradox. En fait, je n'ai pas apprécié du tout
que PC Soft ont fait tout pour mettre la responsabilité dans le coin de
Windows, plutôt que de résoudre le problème. De même avec les
difficultés avec les requêtes HF sur des fichiers partagés.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données. C'est clairement l'accès fichier choisi
par PC Soft qui est en cause puisque inexistant avec d'autre produits,
tels que Visual Foxpro ou Paradox. En fait, je n'ai pas apprécié du tout
que PC Soft ont fait tout pour mettre la responsabilité dans le coin de
Windows, plutôt que de résoudre le problème. De même avec les
difficultés avec les requêtes HF sur des fichiers partagés.
Salut Daniel,
Daniel wrote:
> J'avais lu les tests que tu avais fait sur HF avec les locks et sur
> samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
> le lien qui est très intéressant), je ferais toutefois des conclusi ons
> différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_th read/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d 6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htm
> Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
> me parait gonflé de la part du créateur du logiciel (c'est un peu c omme c'est la faute à
> l'hyperthreading) ;-)
> Le fait de faire une base fichier sans moteur est dans un
> environnement multitache/réseau/multiutilisateur très très diffic ile à
> faire sauf si cette base coopère totalement avec l'OS (ce qui ne
> semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des p ostes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur d es
fichiers partagés. Heureusement, ces problèmes ont été affaibli u n peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
Salut Daniel,
Daniel wrote:
> J'avais lu les tests que tu avais fait sur HF avec les locks et sur
> samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
> le lien qui est très intéressant), je ferais toutefois des conclusi ons
> différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_th read/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d 6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htm
> Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
> me parait gonflé de la part du créateur du logiciel (c'est un peu c omme c'est la faute à
> l'hyperthreading) ;-)
> Le fait de faire une base fichier sans moteur est dans un
> environnement multitache/réseau/multiutilisateur très très diffic ile à
> faire sauf si cette base coopère totalement avec l'OS (ce qui ne
> semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des p ostes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur d es
fichiers partagés. Heureusement, ces problèmes ont été affaibli u n peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
Salut Daniel,
Daniel wrote:
> J'avais lu les tests que tu avais fait sur HF avec les locks et sur
> samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
> le lien qui est très intéressant), je ferais toutefois des conclusi ons
> différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_th read/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d 6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htm
> Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
> me parait gonflé de la part du créateur du logiciel (c'est un peu c omme c'est la faute à
> l'hyperthreading) ;-)
> Le fait de faire une base fichier sans moteur est dans un
> environnement multitache/réseau/multiutilisateur très très diffic ile à
> faire sauf si cette base coopère totalement avec l'OS (ce qui ne
> semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des p ostes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur d es
fichiers partagés. Heureusement, ces problèmes ont été affaibli u n peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
mat writes:Salut Daniel,
Daniel wrote:J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htmAujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des postes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Il me semble que paradox ajoute une couche intermédiare qui est le
bde.Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Je suis d'accord concernant la durée de vie des DB et de la version de
l'OS toutefois il faut admettre qu'on rencontre ce problème de
versionning plus sur les OS de Microsoft.Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
avec partage Samba, j'avais fait quelques tests comparatifs entre
MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
lorsqu'il y avait un seul client, dès le 2ème client Mysql et
postgresql prenaient l'avantage. A partir de 5 clients simultanés les
temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
rapide pour HF) et du SQL pour les autres bases.C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
concernant paradox je pense que le BDE doit y apporter une bonne part.En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur des
fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
J'apprécie ce thread , et qui nous permet de partager nos avis et
expériences diverses et variées sur Windev/HF sans être un troll.
cordialement,
mat <NoSPAM-mnobs@bluemail.ch> writes:
Salut Daniel,
Daniel wrote:
J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htm
Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des postes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Il me semble que paradox ajoute une couche intermédiare qui est le
bde.
Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.
Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Je suis d'accord concernant la durée de vie des DB et de la version de
l'OS toutefois il faut admettre qu'on rencontre ce problème de
versionning plus sur les OS de Microsoft.
Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
avec partage Samba, j'avais fait quelques tests comparatifs entre
MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
lorsqu'il y avait un seul client, dès le 2ème client Mysql et
postgresql prenaient l'avantage. A partir de 5 clients simultanés les
temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
rapide pour HF) et du SQL pour les autres bases.
C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
concernant paradox je pense que le BDE doit y apporter une bonne part.
En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur des
fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
J'apprécie ce thread , et qui nous permet de partager nos avis et
expériences diverses et variées sur Windev/HF sans être un troll.
cordialement,
mat writes:Salut Daniel,
Daniel wrote:J'avais lu les tests que tu avais fait sur HF avec les locks et sur
samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
le lien qui est très intéressant), je ferais toutefois des conclusions
différentes sur HF.
Je suppose tu te réfère à celui-ci :
http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb4d6e5c401c4c
Un lien sur mon rapport à ce sujet (en anglais) :
http://f16.parsimony.net/forum28986/messages/17985.htmAujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
l'hyperthreading) ;-)
Le fait de faire une base fichier sans moteur est dans un
environnement multitache/réseau/multiutilisateur très très difficile à
faire sauf si cette base coopère totalement avec l'OS (ce qui ne
semble pas être le cas).
oui, mais je distingue quand-même entre deux choses: problèmes crées
par l'OS et ceux créés par l'outil de développement. J'ai suivi dans
différents forums le problème de corruption de fichiers HF ou indexes
HF. Je le considère dans le premier groupe car, sauf erreur grave de
ma part, il peut être réglé avec une configuration adéquate des postes
de travail (clients) par la desactivation des caches réseau et
OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
avoir lu des rapports de gens disant qu'ils ont toujours le problème
après avoir fait ces modifications. J'aimerais bien être informé si
quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
au forum est d'apprendre par échange d'informations.
J'ai des installations dans plusieurs pays (avec des "environnements"
très variables) utilisant des fichiers Paradox et le seul problème
massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
vers W2K, et le fournisseur du hardware n'était pas au courant des
problèmes avec les OpLocks (aucun souci auparavant lors des
installations W3.11 et 98SE).
Il me semble que paradox ajoute une couche intermédiare qui est le
bde.Un autre facteur sont les protocoles de
réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
postes.
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.Ca ralenti les postes sous W98 mais évite des problèmes. Les
autres problèmes étaient toujours dûs à des admins qui arrêtent le
serveur sans informer les utilisateurs, des pannes de courant sur les
postes, des pertes de connexion réseau plus délicats à l'époque de
DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
une durée de vie bien plus longue qu'une version de l'OS.
Je suis d'accord concernant la durée de vie des DB et de la version de
l'OS toutefois il faut admettre qu'on rencontre ce problème de
versionning plus sur les OS de Microsoft.Par contre, un problème de la 2e catégorie, dû à HF, est le fait que
l'accès fichier est ralenti à cause d'accès concurrentiels avec
modification aux mêmes données.
J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
avec partage Samba, j'avais fait quelques tests comparatifs entre
MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
lorsqu'il y avait un seul client, dès le 2ème client Mysql et
postgresql prenaient l'avantage. A partir de 5 clients simultanés les
temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
rapide pour HF) et du SQL pour les autres bases.C'est clairement l'accès fichier
choisi par PC Soft qui est en cause puisque inexistant avec d'autre
produits, tels que Visual Foxpro ou Paradox.
Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
concernant paradox je pense que le BDE doit y apporter une bonne part.En fait, je n'ai pas
apprécié du tout que PC Soft ont fait tout pour mettre la
responsabilité dans le coin de Windows, plutôt que de résoudre le
problème. De même avec les difficultés avec les requêtes HF sur des
fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
par le gain de rapidité des processeurs et l'augmentation de RAM sur
les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
le comportement de l'éditeur.
J'apprécie ce thread , et qui nous permet de partager nos avis et
expériences diverses et variées sur Windev/HF sans être un troll.
cordialement,
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Pascal ROY wrote:Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
à mon avis, tu as tort... les fichiers Paradox ont une stabilité
incroyable (je n'ai pas d'actions de Borland... :-) ), sous condition
que le réseau/postes de travail soient configurés correctement.
En plus,
on peut très bien re-indexer/compacter les fichiers (ça s'appelle
restructurer), c'est du standard. Mais je ne voulais pas parler de
Paradox, mais dire qu'il me semble que ce problème d'index est le même
pour toutes les fichiers partagés avec postes de travail mal configurés.
salutations
mat
Pascal ROY wrote:
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
à mon avis, tu as tort... les fichiers Paradox ont une stabilité
incroyable (je n'ai pas d'actions de Borland... :-) ), sous condition
que le réseau/postes de travail soient configurés correctement.
En plus,
on peut très bien re-indexer/compacter les fichiers (ça s'appelle
restructurer), c'est du standard. Mais je ne voulais pas parler de
Paradox, mais dire qu'il me semble que ce problème d'index est le même
pour toutes les fichiers partagés avec postes de travail mal configurés.
salutations
mat
Pascal ROY wrote:Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
à mon avis, tu as tort... les fichiers Paradox ont une stabilité
incroyable (je n'ai pas d'actions de Borland... :-) ), sous condition
que le réseau/postes de travail soient configurés correctement.
En plus,
on peut très bien re-indexer/compacter les fichiers (ça s'appelle
restructurer), c'est du standard. Mais je ne voulais pas parler de
Paradox, mais dire qu'il me semble que ce problème d'index est le même
pour toutes les fichiers partagés avec postes de travail mal configurés.
salutations
mat
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.
Concernant NetBEUI, c'est loin d'être du standard, celà me fait penser
à l'appletalk.
Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
ensuite sur NetBios ou Samba afin de résoudre au mieux les problèmes,
car sans la couche application ton réseau ne fonctionnera pas.
Il me semble que tu as pas mal travaillé sur l'optimisation de la
configuration de Samba.
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Je rappelle que j'utilise WD55 et WD75 tout les jours ! Je ne crache
pas dans la soupe. Simplement je rage contre PCSoft car ce produit etait
à la base tellement prometteur !
Quand je vois tout ce qui est fait pour le marketing, et tout ce qui
n'est pas fait pour que le produit réponde aux pub, ça m'irrite un peu
beaucoup, ...
Pascal
Daniel a écrit :
> mat writes:
>
>
>>Salut Daniel,
>>
>>Daniel wrote:
>>
>>>J'avais lu les tests que tu avais fait sur HF avec les locks et sur
>>>samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
>>>le lien qui est très intéressant), je ferais toutefois des conclus ions
>>>différentes sur HF.
>>
>>Je suppose tu te réfère à celui-ci :
>>http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_ thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb 4d6e5c401c4c
>>
>>Un lien sur mon rapport à ce sujet (en anglais) :
>>http://f16.parsimony.net/forum28986/messages/17985.htm
>>
>>
>>>Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
>>>me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
>>>l'hyperthreading) ;-)
>>>Le fait de faire une base fichier sans moteur est dans un
>>>environnement multitache/réseau/multiutilisateur très très diffi cile à
>>>faire sauf si cette base coopère totalement avec l'OS (ce qui ne
>>>semble pas être le cas).
>>
>>oui, mais je distingue quand-même entre deux choses: problèmes cr ées
>>par l'OS et ceux créés par l'outil de développement. J'ai suivi d ans
>>différents forums le problème de corruption de fichiers HF ou index es
>>HF. Je le considère dans le premier groupe car, sauf erreur grave de
>>ma part, il peut être réglé avec une configuration adéquate des postes
>>de travail (clients) par la desactivation des caches réseau et
>>OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
>>avoir lu des rapports de gens disant qu'ils ont toujours le problème
>>après avoir fait ces modifications. J'aimerais bien être informé si
>>quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
>>au forum est d'apprendre par échange d'informations.
>>
>>J'ai des installations dans plusieurs pays (avec des "environnements"
>>très variables) utilisant des fichiers Paradox et le seul problème
>>massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
>>lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
>>vers W2K, et le fournisseur du hardware n'était pas au courant des
>>problèmes avec les OpLocks (aucun souci auparavant lors des
>>installations W3.11 et 98SE).
>
>
> Il me semble que paradox ajoute une couche intermédiare qui est le
> bde.
>
>
>>Un autre facteur sont les protocoles de
>>réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
>>avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
>>postes.
>
> Concernant NetBEUI, c'est loin d'être du standard, celà me fait pen ser
> à l'appletalk.
> Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
> ensuite sur NetBios ou Samba afin de résoudre au mieux les problème s,
> car sans la couche application ton réseau ne fonctionnera pas.
> Il me semble que tu as pas mal travaillé sur l'optimisation de la
> configuration de Samba.
>
>
>>Ca ralenti les postes sous W98 mais évite des problèmes. Les
>>autres problèmes étaient toujours dûs à des admins qui arrête nt le
>>serveur sans informer les utilisateurs, des pannes de courant sur les
>>postes, des pertes de connexion réseau plus délicats à l'époque de
>>DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
>>une durée de vie bien plus longue qu'une version de l'OS.
>
> Je suis d'accord concernant la durée de vie des DB et de la version de
> l'OS toutefois il faut admettre qu'on rencontre ce problème de
> versionning plus sur les OS de Microsoft.
>
>
>
>>Par contre, un problème de la 2e catégorie, dû à HF, est le fai t que
>>l'accès fichier est ralenti à cause d'accès concurrentiels avec
>>modification aux mêmes données.
>
>
> J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
> avec partage Samba, j'avais fait quelques tests comparatifs entre
> MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
> journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
> lorsqu'il y avait un seul client, dès le 2ème client Mysql et
> postgresql prenaient l'avantage. A partir de 5 clients simultanés les
> temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
> j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
> rapide pour HF) et du SQL pour les autres bases.
>
>
>
>>C'est clairement l'accès fichier
>>choisi par PC Soft qui est en cause puisque inexistant avec d'autre
>>produits, tels que Visual Foxpro ou Paradox.
>
> Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
> concernant paradox je pense que le BDE doit y apporter une bonne part.
>
>
>
>>En fait, je n'ai pas
>>apprécié du tout que PC Soft ont fait tout pour mettre la
>>responsabilité dans le coin de Windows, plutôt que de résoudre le
>>problème. De même avec les difficultés avec les requêtes HF sur des
>>fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
>>par le gain de rapidité des processeurs et l'augmentation de RAM sur
>>les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
>>le comportement de l'éditeur.
>>
>
> J'apprécie ce thread , et qui nous permet de partager nos avis et
> expériences diverses et variées sur Windev/HF sans être un troll.
>
> cordialement,
>
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Je rappelle que j'utilise WD55 et WD75 tout les jours ! Je ne crache
pas dans la soupe. Simplement je rage contre PCSoft car ce produit etait
à la base tellement prometteur !
Quand je vois tout ce qui est fait pour le marketing, et tout ce qui
n'est pas fait pour que le produit réponde aux pub, ça m'irrite un peu
beaucoup, ...
Pascal
Daniel a écrit :
> mat <NoSPAM-mnobs@bluemail.ch> writes:
>
>
>>Salut Daniel,
>>
>>Daniel wrote:
>>
>>>J'avais lu les tests que tu avais fait sur HF avec les locks et sur
>>>samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
>>>le lien qui est très intéressant), je ferais toutefois des conclus ions
>>>différentes sur HF.
>>
>>Je suppose tu te réfère à celui-ci :
>>http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_ thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb 4d6e5c401c4c
>>
>>Un lien sur mon rapport à ce sujet (en anglais) :
>>http://f16.parsimony.net/forum28986/messages/17985.htm
>>
>>
>>>Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
>>>me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
>>>l'hyperthreading) ;-)
>>>Le fait de faire une base fichier sans moteur est dans un
>>>environnement multitache/réseau/multiutilisateur très très diffi cile à
>>>faire sauf si cette base coopère totalement avec l'OS (ce qui ne
>>>semble pas être le cas).
>>
>>oui, mais je distingue quand-même entre deux choses: problèmes cr ées
>>par l'OS et ceux créés par l'outil de développement. J'ai suivi d ans
>>différents forums le problème de corruption de fichiers HF ou index es
>>HF. Je le considère dans le premier groupe car, sauf erreur grave de
>>ma part, il peut être réglé avec une configuration adéquate des postes
>>de travail (clients) par la desactivation des caches réseau et
>>OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
>>avoir lu des rapports de gens disant qu'ils ont toujours le problème
>>après avoir fait ces modifications. J'aimerais bien être informé si
>>quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
>>au forum est d'apprendre par échange d'informations.
>>
>>J'ai des installations dans plusieurs pays (avec des "environnements"
>>très variables) utilisant des fichiers Paradox et le seul problème
>>massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
>>lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
>>vers W2K, et le fournisseur du hardware n'était pas au courant des
>>problèmes avec les OpLocks (aucun souci auparavant lors des
>>installations W3.11 et 98SE).
>
>
> Il me semble que paradox ajoute une couche intermédiare qui est le
> bde.
>
>
>>Un autre facteur sont les protocoles de
>>réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
>>avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
>>postes.
>
> Concernant NetBEUI, c'est loin d'être du standard, celà me fait pen ser
> à l'appletalk.
> Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
> ensuite sur NetBios ou Samba afin de résoudre au mieux les problème s,
> car sans la couche application ton réseau ne fonctionnera pas.
> Il me semble que tu as pas mal travaillé sur l'optimisation de la
> configuration de Samba.
>
>
>>Ca ralenti les postes sous W98 mais évite des problèmes. Les
>>autres problèmes étaient toujours dûs à des admins qui arrête nt le
>>serveur sans informer les utilisateurs, des pannes de courant sur les
>>postes, des pertes de connexion réseau plus délicats à l'époque de
>>DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
>>une durée de vie bien plus longue qu'une version de l'OS.
>
> Je suis d'accord concernant la durée de vie des DB et de la version de
> l'OS toutefois il faut admettre qu'on rencontre ce problème de
> versionning plus sur les OS de Microsoft.
>
>
>
>>Par contre, un problème de la 2e catégorie, dû à HF, est le fai t que
>>l'accès fichier est ralenti à cause d'accès concurrentiels avec
>>modification aux mêmes données.
>
>
> J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
> avec partage Samba, j'avais fait quelques tests comparatifs entre
> MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
> journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
> lorsqu'il y avait un seul client, dès le 2ème client Mysql et
> postgresql prenaient l'avantage. A partir de 5 clients simultanés les
> temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
> j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
> rapide pour HF) et du SQL pour les autres bases.
>
>
>
>>C'est clairement l'accès fichier
>>choisi par PC Soft qui est en cause puisque inexistant avec d'autre
>>produits, tels que Visual Foxpro ou Paradox.
>
> Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
> concernant paradox je pense que le BDE doit y apporter une bonne part.
>
>
>
>>En fait, je n'ai pas
>>apprécié du tout que PC Soft ont fait tout pour mettre la
>>responsabilité dans le coin de Windows, plutôt que de résoudre le
>>problème. De même avec les difficultés avec les requêtes HF sur des
>>fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
>>par le gain de rapidité des processeurs et l'augmentation de RAM sur
>>les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
>>le comportement de l'éditeur.
>>
>
> J'apprécie ce thread , et qui nous permet de partager nos avis et
> expériences diverses et variées sur Windev/HF sans être un troll.
>
> cordialement,
>
Juste un point pour dire que les fichiers Paradox et le BDE ne
sont pas exempt de gros soucis dans les index. En plus Borland
ne fournit pas en standard de fonction pour le Pack et le Reindex,
il faut se les palucher soit même ou les trouver sur le net.
Donc, même moi qui est crié contre Windev, je place bémol sur les
outils Borland. :-)
Je rappelle que j'utilise WD55 et WD75 tout les jours ! Je ne crache
pas dans la soupe. Simplement je rage contre PCSoft car ce produit etait
à la base tellement prometteur !
Quand je vois tout ce qui est fait pour le marketing, et tout ce qui
n'est pas fait pour que le produit réponde aux pub, ça m'irrite un peu
beaucoup, ...
Pascal
Daniel a écrit :
> mat writes:
>
>
>>Salut Daniel,
>>
>>Daniel wrote:
>>
>>>J'avais lu les tests que tu avais fait sur HF avec les locks et sur
>>>samba. Mais malgrès l'analyse que tu en fais (si tu peux republier
>>>le lien qui est très intéressant), je ferais toutefois des conclus ions
>>>différentes sur HF.
>>
>>Je suppose tu te réfère à celui-ci :
>>http://groups.google.com/group/fr.comp.developpement.agl.windev/browse_ thread/thread/90c63f5699b96c1e/51cb4d6e5c401c4c?q=mat+samba&rnum=2#51cb 4d6e5c401c4c
>>
>>Un lien sur mon rapport à ce sujet (en anglais) :
>>http://f16.parsimony.net/forum28986/messages/17985.htm
>>
>>
>>>Aujourd'hui, l'excuse de dire que c'est Windows ou sa couche netbios
>>>me parait gonflé de la part du créateur du logiciel (c'est un peu comme c'est la faute à
>>>l'hyperthreading) ;-)
>>>Le fait de faire une base fichier sans moteur est dans un
>>>environnement multitache/réseau/multiutilisateur très très diffi cile à
>>>faire sauf si cette base coopère totalement avec l'OS (ce qui ne
>>>semble pas être le cas).
>>
>>oui, mais je distingue quand-même entre deux choses: problèmes cr ées
>>par l'OS et ceux créés par l'outil de développement. J'ai suivi d ans
>>différents forums le problème de corruption de fichiers HF ou index es
>>HF. Je le considère dans le premier groupe car, sauf erreur grave de
>>ma part, il peut être réglé avec une configuration adéquate des postes
>>de travail (clients) par la desactivation des caches réseau et
>>OpLocks. Et cela sans aucune perte de rapidité. Je ne me rappelle pas
>>avoir lu des rapports de gens disant qu'ils ont toujours le problème
>>après avoir fait ces modifications. J'aimerais bien être informé si
>>quelqu'un pouvait infirmer mon expérience. Ma motivation de participer
>>au forum est d'apprendre par échange d'informations.
>>
>>J'ai des installations dans plusieurs pays (avec des "environnements"
>>très variables) utilisant des fichiers Paradox et le seul problème
>>massif que j'ai eu en plus de 10 ans d'usage en réseau local c'était
>>lorsqu'un client a fait faire une mise à jour des ordinateurs de W98SE
>>vers W2K, et le fournisseur du hardware n'était pas au courant des
>>problèmes avec les OpLocks (aucun souci auparavant lors des
>>installations W3.11 et 98SE).
>
>
> Il me semble que paradox ajoute une couche intermédiare qui est le
> bde.
>
>
>>Un autre facteur sont les protocoles de
>>réseau. Sous W98SE le mieux c'est NetBEUI, tandis qu'avec des machines
>>avec W2K il vaut mieux n'utiliser que TCP/IP pour toutes les
>>postes.
>
> Concernant NetBEUI, c'est loin d'être du standard, celà me fait pen ser
> à l'appletalk.
> Concernant le réseau TCP/IP, Mat tu oublies de dire que tu passes
> ensuite sur NetBios ou Samba afin de résoudre au mieux les problème s,
> car sans la couche application ton réseau ne fonctionnera pas.
> Il me semble que tu as pas mal travaillé sur l'optimisation de la
> configuration de Samba.
>
>
>>Ca ralenti les postes sous W98 mais évite des problèmes. Les
>>autres problèmes étaient toujours dûs à des admins qui arrête nt le
>>serveur sans informer les utilisateurs, des pannes de courant sur les
>>postes, des pertes de connexion réseau plus délicats à l'époque de
>>DOS, donc rien de grave. Faut pas oublier non plus qu'un produit DB a
>>une durée de vie bien plus longue qu'une version de l'OS.
>
> Je suis d'accord concernant la durée de vie des DB et de la version de
> l'OS toutefois il faut admettre qu'on rencontre ce problème de
> versionning plus sur les OS de Microsoft.
>
>
>
>>Par contre, un problème de la 2e catégorie, dû à HF, est le fai t que
>>l'accès fichier est ralenti à cause d'accès concurrentiels avec
>>modification aux mêmes données.
>
>
> J'abonde dans ton sens sur une base HF réseau, en réseau switché 100MB
> avec partage Samba, j'avais fait quelques tests comparatifs entre
> MySQL(innodb et log binaire), POstgresql 8 et HF (transaction, et
> journaux). Lors d'insert-update HF était 1 à 2 fois plus rapide
> lorsqu'il y avait un seul client, dès le 2ème client Mysql et
> postgresql prenaient l'avantage. A partir de 5 clients simultanés les
> temps sur HF augmentaient de façon exponentiel. Pour faire ces tests
> j'avais fait du Hlangage pour HF (car il est indiqué que c'est plus
> rapide pour HF) et du SQL pour les autres bases.
>
>
>
>>C'est clairement l'accès fichier
>>choisi par PC Soft qui est en cause puisque inexistant avec d'autre
>>produits, tels que Visual Foxpro ou Paradox.
>
> Je suis d'accord (concernant Visual Foxpro je ne l'ai jamais utilisé),
> concernant paradox je pense que le BDE doit y apporter une bonne part.
>
>
>
>>En fait, je n'ai pas
>>apprécié du tout que PC Soft ont fait tout pour mettre la
>>responsabilité dans le coin de Windows, plutôt que de résoudre le
>>problème. De même avec les difficultés avec les requêtes HF sur des
>>fichiers partagés. Heureusement, ces problèmes ont été affaibli un peu
>>par le gain de rapidité des processeurs et l'augmentation de RAM sur
>>les postes de travail ces derniers 2 ans. Mais cela n'excuse en rien
>>le comportement de l'éditeur.
>>
>
> J'apprécie ce thread , et qui nous permet de partager nos avis et
> expériences diverses et variées sur Windev/HF sans être un troll.
>
> cordialement,
>
> a écrit dans le message de
Bonjour,
Je pense, comme beaucoup, que Windev a acquit ses véritables lettres
de noblesse à partir de la version 8, et que la 9 est vraiment
sympathiquement aboutie.
Pour moi les versions inférieures n'ont plus droit de cité, car
réellement dépassées
Pour moi une application de gestion sans export word et excel (ou leurs
equivalents openoffice pour ceux qui préfèrent, sans PDF et sans
envoi de mail (ce qui est automatique en 9, vous le savez
certainement), ou encore les fenêtres sans ancrages et sans spiltters,
c'est de la préhistoire !
Chacun fait ce qui lui plait, mais parler de "windev" quand on parle de
la 7.5, pour moi, ce n'est pas parler de "windev d'aujourd'hui", c'est
parler d'un passé révolu
Celles et ceux qui sont en 9 devraient être de mon avis, je pense.
Que ceux qui sont encore en 7.5 essayent de tester la 9, je pense
qu'ils seront favorablement étonné (à ce sujet, dommage que Pcsoft
ne diffuse pas de démo en 9)
> <vanessa.anglet@hotmail.com> a écrit dans le message de
Bonjour,
Je pense, comme beaucoup, que Windev a acquit ses véritables lettres
de noblesse à partir de la version 8, et que la 9 est vraiment
sympathiquement aboutie.
Pour moi les versions inférieures n'ont plus droit de cité, car
réellement dépassées
Pour moi une application de gestion sans export word et excel (ou leurs
equivalents openoffice pour ceux qui préfèrent, sans PDF et sans
envoi de mail (ce qui est automatique en 9, vous le savez
certainement), ou encore les fenêtres sans ancrages et sans spiltters,
c'est de la préhistoire !
Chacun fait ce qui lui plait, mais parler de "windev" quand on parle de
la 7.5, pour moi, ce n'est pas parler de "windev d'aujourd'hui", c'est
parler d'un passé révolu
Celles et ceux qui sont en 9 devraient être de mon avis, je pense.
Que ceux qui sont encore en 7.5 essayent de tester la 9, je pense
qu'ils seront favorablement étonné (à ce sujet, dommage que Pcsoft
ne diffuse pas de démo en 9)
> a écrit dans le message de
Bonjour,
Je pense, comme beaucoup, que Windev a acquit ses véritables lettres
de noblesse à partir de la version 8, et que la 9 est vraiment
sympathiquement aboutie.
Pour moi les versions inférieures n'ont plus droit de cité, car
réellement dépassées
Pour moi une application de gestion sans export word et excel (ou leurs
equivalents openoffice pour ceux qui préfèrent, sans PDF et sans
envoi de mail (ce qui est automatique en 9, vous le savez
certainement), ou encore les fenêtres sans ancrages et sans spiltters,
c'est de la préhistoire !
Chacun fait ce qui lui plait, mais parler de "windev" quand on parle de
la 7.5, pour moi, ce n'est pas parler de "windev d'aujourd'hui", c'est
parler d'un passé révolu
Celles et ceux qui sont en 9 devraient être de mon avis, je pense.
Que ceux qui sont encore en 7.5 essayent de tester la 9, je pense
qu'ils seront favorablement étonné (à ce sujet, dommage que Pcsoft
ne diffuse pas de démo en 9)
