-----Message d'origine-----
Bonjour Philippe!
Le conseil court: evitez d'utiliser Access sur une
liaison a faible debit,
c'est beaucoup trop lent et risque.
L'explication un peu plus longue: vous parlez d'une base
mdb et d'un frontal
mde. Il y a de grandes chances que vous ayez developpe
les formulaires sur
le modele classique d'Access, qui est d'avoir une table
(ou une requete)
sous-jascente a un formulaire, et des touches avant-
arriere pour parcourir
l'ensemble des enregistrements. Le probleme avec ca,
c'est que premierement
le traitement des donnees se fait au niveau local: Jet
sur la machine client
charge toute la table (ou au moins l'index correspondant
a cette table),
cela fait donc un trajet de la table sur la liaison. S'il
y a d'autres
tables impliquees dans cette requete sous-jascente (et
quelle application
serieuse n'a besoin que d'une table?) elle transitent
aussi sur le fil.
Cela explique un delai notable dans l'ouverture des
formulaires (au point ou
ce n'est parfois pas utilisable).
Le fichier .ldb est mis a jour par l'application Jet du
cote client. Ce
fichier centralise le decompte des utilisateurs (en fait
le nombre
d'applications Jet qui ont ouvert la base), avec le nom
des objets utilises
et leur etat, ainsi que les verrouillage
d'enregistrements eventuels. Si le
poste client n'est pas capable de mettre ce fichier a
jour de facon "propre"
(c'est a dire en des temps raisonnables, sans faire trop
d'essais
infructueux, en n'ayant pas des timeouts qui empechent
les operations de se
derouler de facon normale), il y a de grande chances que
l'on ait des
collisions dans un scenario multi-utilisateur.
Brefle, pour une application utilisee sur une liaison
lente, il faut du
veritable client-serveur, avec le poste client ne
travaillant que sur un
petit ensemble de donnees a la fois. Deux autres pistes
seraient peut-etre a
explorer: une application mettant en oeuvre la
replication, ou une emulation
de terminal (genre Terminal Server).
Quand vous parlez d'une liaison a 512K, il s'agit
probablement de
512kbits/s, soit 64kOctets/s. C'est beaucoup trop lent
pour Access, environ
d'un ordre de magnitude. La liaison hertzienne, elle, a
10Mbits/s donnerait
a peine plus d'un mega octet par seconde, ce qui est
plutot poussif avec
Access.
Voila, j'espere que ca vous donne des pointeurs...
--
Daniel :-)
Computing Technologies International - www.computing-
tech.com - We
provide solutions...
"Philippe" wrote in
message
news:1ce5601c422ea$d923cbf0$
Bonjour,
J'ai une application de gestion du courrier utilisée en
local par plusieurs utilisateurs sans problème.
J'ai sur le serveur une base Mde pour le programme et une
base Mdb pour les tables attachées.
Pour les sites distants (débits variables de 512K à 2Mo
voir une site en liaison hertzienne à 10Mo) , j'ai le run
time access et le Mde en local. les temps de réponse ne
sont pas bons et il y a même des plantages avec parfois
obligation de réparer la base.
Quelqu'un a t-il une expérience ou des conseils en la
matière.
Merci de votre aide
Philippe
.
-----Message d'origine-----
Bonjour Philippe!
Le conseil court: evitez d'utiliser Access sur une
liaison a faible debit,
c'est beaucoup trop lent et risque.
L'explication un peu plus longue: vous parlez d'une base
mdb et d'un frontal
mde. Il y a de grandes chances que vous ayez developpe
les formulaires sur
le modele classique d'Access, qui est d'avoir une table
(ou une requete)
sous-jascente a un formulaire, et des touches avant-
arriere pour parcourir
l'ensemble des enregistrements. Le probleme avec ca,
c'est que premierement
le traitement des donnees se fait au niveau local: Jet
sur la machine client
charge toute la table (ou au moins l'index correspondant
a cette table),
cela fait donc un trajet de la table sur la liaison. S'il
y a d'autres
tables impliquees dans cette requete sous-jascente (et
quelle application
serieuse n'a besoin que d'une table?) elle transitent
aussi sur le fil.
Cela explique un delai notable dans l'ouverture des
formulaires (au point ou
ce n'est parfois pas utilisable).
Le fichier .ldb est mis a jour par l'application Jet du
cote client. Ce
fichier centralise le decompte des utilisateurs (en fait
le nombre
d'applications Jet qui ont ouvert la base), avec le nom
des objets utilises
et leur etat, ainsi que les verrouillage
d'enregistrements eventuels. Si le
poste client n'est pas capable de mettre ce fichier a
jour de facon "propre"
(c'est a dire en des temps raisonnables, sans faire trop
d'essais
infructueux, en n'ayant pas des timeouts qui empechent
les operations de se
derouler de facon normale), il y a de grande chances que
l'on ait des
collisions dans un scenario multi-utilisateur.
Brefle, pour une application utilisee sur une liaison
lente, il faut du
veritable client-serveur, avec le poste client ne
travaillant que sur un
petit ensemble de donnees a la fois. Deux autres pistes
seraient peut-etre a
explorer: une application mettant en oeuvre la
replication, ou une emulation
de terminal (genre Terminal Server).
Quand vous parlez d'une liaison a 512K, il s'agit
probablement de
512kbits/s, soit 64kOctets/s. C'est beaucoup trop lent
pour Access, environ
d'un ordre de magnitude. La liaison hertzienne, elle, a
10Mbits/s donnerait
a peine plus d'un mega octet par seconde, ce qui est
plutot poussif avec
Access.
Voila, j'espere que ca vous donne des pointeurs...
--
Daniel :-)
Computing Technologies International - www.computing-
tech.com - We
provide solutions...
"Philippe" <anonymous@discussions.microsoft.com> wrote in
message
news:1ce5601c422ea$d923cbf0$a301280a@phx.gbl...
Bonjour,
J'ai une application de gestion du courrier utilisée en
local par plusieurs utilisateurs sans problème.
J'ai sur le serveur une base Mde pour le programme et une
base Mdb pour les tables attachées.
Pour les sites distants (débits variables de 512K à 2Mo
voir une site en liaison hertzienne à 10Mo) , j'ai le run
time access et le Mde en local. les temps de réponse ne
sont pas bons et il y a même des plantages avec parfois
obligation de réparer la base.
Quelqu'un a t-il une expérience ou des conseils en la
matière.
Merci de votre aide
Philippe
.
-----Message d'origine-----
Bonjour Philippe!
Le conseil court: evitez d'utiliser Access sur une
liaison a faible debit,
c'est beaucoup trop lent et risque.
L'explication un peu plus longue: vous parlez d'une base
mdb et d'un frontal
mde. Il y a de grandes chances que vous ayez developpe
les formulaires sur
le modele classique d'Access, qui est d'avoir une table
(ou une requete)
sous-jascente a un formulaire, et des touches avant-
arriere pour parcourir
l'ensemble des enregistrements. Le probleme avec ca,
c'est que premierement
le traitement des donnees se fait au niveau local: Jet
sur la machine client
charge toute la table (ou au moins l'index correspondant
a cette table),
cela fait donc un trajet de la table sur la liaison. S'il
y a d'autres
tables impliquees dans cette requete sous-jascente (et
quelle application
serieuse n'a besoin que d'une table?) elle transitent
aussi sur le fil.
Cela explique un delai notable dans l'ouverture des
formulaires (au point ou
ce n'est parfois pas utilisable).
Le fichier .ldb est mis a jour par l'application Jet du
cote client. Ce
fichier centralise le decompte des utilisateurs (en fait
le nombre
d'applications Jet qui ont ouvert la base), avec le nom
des objets utilises
et leur etat, ainsi que les verrouillage
d'enregistrements eventuels. Si le
poste client n'est pas capable de mettre ce fichier a
jour de facon "propre"
(c'est a dire en des temps raisonnables, sans faire trop
d'essais
infructueux, en n'ayant pas des timeouts qui empechent
les operations de se
derouler de facon normale), il y a de grande chances que
l'on ait des
collisions dans un scenario multi-utilisateur.
Brefle, pour une application utilisee sur une liaison
lente, il faut du
veritable client-serveur, avec le poste client ne
travaillant que sur un
petit ensemble de donnees a la fois. Deux autres pistes
seraient peut-etre a
explorer: une application mettant en oeuvre la
replication, ou une emulation
de terminal (genre Terminal Server).
Quand vous parlez d'une liaison a 512K, il s'agit
probablement de
512kbits/s, soit 64kOctets/s. C'est beaucoup trop lent
pour Access, environ
d'un ordre de magnitude. La liaison hertzienne, elle, a
10Mbits/s donnerait
a peine plus d'un mega octet par seconde, ce qui est
plutot poussif avec
Access.
Voila, j'espere que ca vous donne des pointeurs...
--
Daniel :-)
Computing Technologies International - www.computing-
tech.com - We
provide solutions...
"Philippe" wrote in
message
news:1ce5601c422ea$d923cbf0$
Bonjour,
J'ai une application de gestion du courrier utilisée en
local par plusieurs utilisateurs sans problème.
J'ai sur le serveur une base Mde pour le programme et une
base Mdb pour les tables attachées.
Pour les sites distants (débits variables de 512K à 2Mo
voir une site en liaison hertzienne à 10Mo) , j'ai le run
time access et le Mde en local. les temps de réponse ne
sont pas bons et il y a même des plantages avec parfois
obligation de réparer la base.
Quelqu'un a t-il une expérience ou des conseils en la
matière.
Merci de votre aide
Philippe
.
Par contre connais-tu le produit Webdev de Pc soft, qui
sur le papier semble "formidable" et permet de se
connecter à des bases access, je regarde également vers
cette solution, mais le peu d'infos que j'ai sur ce
produit ne semblent pas aussi "formidables" que sur la
plaquette (pour la migration de l'application access et la
reprise du code).
En outre je suis surpris qu'une "liaison à 10Mbits/s
donnerait a peine plus d'un mega octet par seconde",
comment fais-tu le calcul et est-ce que la distance entre
les 2 sites entre également en ligne de compte pour les
performances.
Par contre connais-tu le produit Webdev de Pc soft, qui
sur le papier semble "formidable" et permet de se
connecter à des bases access, je regarde également vers
cette solution, mais le peu d'infos que j'ai sur ce
produit ne semblent pas aussi "formidables" que sur la
plaquette (pour la migration de l'application access et la
reprise du code).
En outre je suis surpris qu'une "liaison à 10Mbits/s
donnerait a peine plus d'un mega octet par seconde",
comment fais-tu le calcul et est-ce que la distance entre
les 2 sites entre également en ligne de compte pour les
performances.
Par contre connais-tu le produit Webdev de Pc soft, qui
sur le papier semble "formidable" et permet de se
connecter à des bases access, je regarde également vers
cette solution, mais le peu d'infos que j'ai sur ce
produit ne semblent pas aussi "formidables" que sur la
plaquette (pour la migration de l'application access et la
reprise du code).
En outre je suis surpris qu'une "liaison à 10Mbits/s
donnerait a peine plus d'un mega octet par seconde",
comment fais-tu le calcul et est-ce que la distance entre
les 2 sites entre également en ligne de compte pour les
performances.