J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local. Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le fichier
batch (net use p: "serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre en
service une nouvelle version en cours de journée (les utilisateurs ont juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local. Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le fichier
batch (net use p: "\serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre en
service une nouvelle version en cours de journée (les utilisateurs ont juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
J'ai une application Access compilé en MDE avec des données liées qui sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4 megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local. Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le fichier
batch (net use p: "serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre en
service une nouvelle version en cours de journée (les utilisateurs ont juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
Imaginons que je mets mon application locale sur les postes des
utilisateurs, pour ma gestion de la sécurité avec mon fichier .mdw, je
dois
laisser mon .mdw sur le serveur et y accédé par le réseau???
J'ai une application Access compilé en MDE avec des données liées qui
sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de
travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4
megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des
problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local.
Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est
vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le
fichier
batch (net use p: "serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur
fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre
en
service une nouvelle version en cours de journée (les utilisateurs ont
juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à
jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur
un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde
dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais
j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
Imaginons que je mets mon application locale sur les postes des
utilisateurs, pour ma gestion de la sécurité avec mon fichier .mdw, je
dois
laisser mon .mdw sur le serveur et y accédé par le réseau???
J'ai une application Access compilé en MDE avec des données liées qui
sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de
travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4
megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des
problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local.
Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est
vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le
fichier
batch (net use p: "\serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur
fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre
en
service une nouvelle version en cours de journée (les utilisateurs ont
juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à
jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur
un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde
dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais
j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
Imaginons que je mets mon application locale sur les postes des
utilisateurs, pour ma gestion de la sécurité avec mon fichier .mdw, je
dois
laisser mon .mdw sur le serveur et y accédé par le réseau???
J'ai une application Access compilé en MDE avec des données liées qui
sont
sur un serveur SQL. Mon application est sur un serveur et tous les
utilisateurs travaillent dans la même application sur le serveur,
l'application n'est pas pas copier localement sur aucun poste de
travail
des
utilisateurs. Il y a entre 30 et 50 utilisateurs par jours.
Mon problème est que mon application quand elle est compacté est de 4
megs
et que après 4 jours elle devient de 200 megs et après 3 semaines elle
devient de 800 megs. Quand elle devient plus grosse, j'ai des
problèmes
de
performance.
Pourquoi la base de données grossit si rapidement? Et comment puis-je
règlé
ce problème?
Bonjour, Bruno
Avec autant d'utilisateurs, l'obésité chronique de ta base ne m'étonne
absolument pas!
Il faut vraiment que tu trouves un moyen de répliquer la base application
sur tous les postes.
Personnellement, j'ai créé un fichier batch qui se lance à l'ouverture de
session et qui recopie la dernière base appli dans un répertoire local.
Si
le menu Démarrer est redirigé sur un serveur par stratégie, c'est
vraiment
très simple.
Concernant la liaison des tables, j'ai créé un lecteur réseau (P:) qui
pointe directement sur le dossier contenant la base des tables sur le
serveur. La commande qui crée ce lecteur est aussi présente dans le
fichier
batch (net use p: "serveurpartagedossier").
Avec ces deux astuces, les utilisateurs ont toujours une base appli
compactée (au moins au démarrage), ils ont chacun la leur (si leur
fichier
se corrompt, pas besoin de déconnecter tout le monde) et je peux mettre
en
service une nouvelle version en cours de journée (les utilisateurs ont
juste
à cliquer sur le batch dans leur menu Démarrer/Démarrage pour être à
jour).
Pour les utilisateurs utilisant TSE (ouverture de session à distance sur
un
serveur dédié), j'ai même adapté le batch pour que le fichier mdb (mde
dans
ton cas) copié en local utilise comme nom le nom de l'utilisateur (copy
p:mabase.mdb c:%username%.mdb). Ensuite, tu crées un raccourci vers
c:%username%.mdb et ça marche !!! Cette solution peut aussi fonctionner
pour des utilisateurs ayant des clients légers sans disque dur
Désolé de ne pas répondre à ta question (pourquoi la base grossit) mais
j'ai
peur de dire des bêtises sur ce sujet que je ne maîtrise pas...
Bonne continuation
