On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
On 27 fév, 10:23, "J'ai-Du-Bois" <duboi...@gmail.com> wrote:
On 26 fév, 21:24, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvr e
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal su r
son poste. Là les liaisons pourront être spécifiques à chaque util isateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:f3ed9
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même f ormat),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modificati on
d'une requête ou d'un formulaire, je suis obligé de les dupliqu er
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne l e
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisat eur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requ ête
serait répercutée sur l'ensemble des données à exploiter. C e serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu' un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter un e
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées su r tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher l e texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combin ée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comm e
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs n e
peuvent pas utiliser deux sources de données différentes à la fo is.
Là, c'est un véritable problème étant donné que cela rend to ut le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récup ère
dans une procédure exécuté automatiquement au démarrage qui t'in dique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à de ux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en trai n
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte de s messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvr e
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal su r
son poste. Là les liaisons pourront être spécifiques à chaque util isateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message denews:f3ed9 fe9-eb1e-432f-9e30-f718725eeeab@d5g2000hsc.googlegroups.com...
On 27 fév, 11:18, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
On 27 fév, 10:23, "J'ai-Du-Bois" <duboi...@gmail.com> wrote:
On 26 fév, 21:24, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même f ormat),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modificati on
d'une requête ou d'un formulaire, je suis obligé de les dupliqu er
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne l e
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisat eur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requ ête
serait répercutée sur l'ensemble des données à exploiter. C e serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu' un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter un e
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées su r tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher l e texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combin ée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comm e
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs n e
peuvent pas utiliser deux sources de données différentes à la fo is.
Là, c'est un véritable problème étant donné que cela rend to ut le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récup ère
dans une procédure exécuté automatiquement au démarrage qui t'in dique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à de ux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en trai n
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte de s messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvr e
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal su r
son poste. Là les liaisons pourront être spécifiques à chaque util isateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:f3ed9
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même f ormat),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modificati on
d'une requête ou d'un formulaire, je suis obligé de les dupliqu er
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne l e
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisat eur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requ ête
serait répercutée sur l'ensemble des données à exploiter. C e serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu' un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter un e
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées su r tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher l e texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combin ée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comm e
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs n e
peuvent pas utiliser deux sources de données différentes à la fo is.
Là, c'est un véritable problème étant donné que cela rend to ut le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récup ère
dans une procédure exécuté automatiquement au démarrage qui t'in dique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à de ux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en trai n
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte de s messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
On 27 fév, 15:15, "Gilbert" wrote:Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).
On 27 fév, 15:15, "Gilbert" <ZZZZgilbert...@tiscali.fr> wrote:
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message denews:f3ed9fe9-eb1e-432f-9e30-f718725eeeab@d5g2000hsc.googlegroups.com...
On 27 fév, 11:18, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
On 27 fév, 10:23, "J'ai-Du-Bois" <duboi...@gmail.com> wrote:
On 26 fév, 21:24, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).
On 27 fév, 15:15, "Gilbert" wrote:Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message
denews:
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même
format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message
denews:f3ed9fe9-eb1e-432f-9e30-f718725eeeab@d5g2000hsc.googlegroups.com...
On 27 fév, 11:18, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
On 27 fév, 10:23, "J'ai-Du-Bois" <duboi...@gmail.com> wrote:
On 26 fév, 21:24, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même
format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileName
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (ou un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur des
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
sur
son poste. Là les liaisons pourront être spécifiques à chaque utilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message
denews:
On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller),
de la base mère dans lesquels des données (toujours le même
format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modification
d'une requête ou d'un formulaire, je suis obligé de les dupliquer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en même
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une requête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose qu'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier ton
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combinée
avec GetOpenFileName). Les tables sont relocalisée toutes seul comme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNameJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le poste
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu récupère
dans une procédure exécuté automatiquement au démarrage qui t'indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en train
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à c haque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles ( en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous le s
postes.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:6747a
On 27 fév, 15:15, "Gilbert" wrote:Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvrela même base "mère" (comme tu l'appelles) située sur un serveur (o u un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur d es
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
surson poste. Là les liaisons pourront être spécifiques à chaque ut ilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message
denews:On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller ),
de la base mère dans lesquels des données (toujours le même
format),sont importées.
Ce système est devenu un vrai cauchemar car à chaque modifica tion
d'une requête ou d'un formulaire, je suis obligé de les dupli quer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
lefais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,il faut que plusieurs utilisateurs puissent se connecter en mêm e
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une req uête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose q u'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
uneréponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier to n
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combi née
avec GetOpenFileName). Les tables sont relocalisée toutes seul co mme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNam eJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le pos te
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu réc upère
dans une procédure exécuté automatiquement au démarrage qui t' indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en tr ain
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à c haque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles ( en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous le s
postes.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message denews:6747a 1c6-d0af-4236-98a4-12c51a966112@p73g2000hsd.googlegroups.com...
On 27 fév, 15:15, "Gilbert" <ZZZZgilbert...@tiscali.fr> wrote:
Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvre
la même base "mère" (comme tu l'appelles) située sur un serveur (o u un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur d es
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
sur
son poste. Là les liaisons pourront être spécifiques à chaque ut ilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message
denews:f3ed9fe9-eb1e-432f-9e30-f718725eeeab@d5g2000hsc.googlegroups.com...
On 27 fév, 11:18, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
On 27 fév, 10:23, "J'ai-Du-Bois" <duboi...@gmail.com> wrote:
On 26 fév, 21:24, Michel_D <Michel.NOS...@orange-ft.com.invalid>
wrote:
Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller ),
de la base mère dans lesquels des données (toujours le même
format),
sont importées.
Ce système est devenu un vrai cauchemar car à chaque modifica tion
d'une requête ou d'un formulaire, je suis obligé de les dupli quer
dans
la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
le
fais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,
il faut que plusieurs utilisateurs puissent se connecter en mêm e
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une req uête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
le
rêve...
J'espère que tout de même que cela peut devenir autre chose q u'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
une
réponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier to n
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -
ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combi née
avec GetOpenFileName). Les tables sont relocalisée toutes seul co mme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNam e
Je ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le pos te
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu réc upère
dans une procédure exécuté automatiquement au démarrage qui t' indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -
- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en tr ain
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -
- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à c haque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles ( en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous le s
postes.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message denews:6747a
On 27 fév, 15:15, "Gilbert" wrote:Bonjour,
Je ne sais pas si j'ai bien interprété ce que tu décris de ton
fonctionnement, mais j'ai l'impression que chacun de tes utilisateurs
ouvrela même base "mère" (comme tu l'appelles) située sur un serveur (o u un
dossier partagé).
Si c'est bien ça tu ne peux effectivement pas avoir des liaisons sur d es
tables différentes en fonction de chaque utilisateur.
Il faut que chacun de tes utilisateurs ait une copie du fichier frontal
surson poste. Là les liaisons pourront être spécifiques à chaque ut ilisateur.
--
Cordialement,
Gilbert
"J'ai-Du-Bois" a écrit dans le message
denews:On 27 fév, 11:18, Michel_D
wrote:On 27 fév, 10:23, "J'ai-Du-Bois" wrote:On 26 fév, 21:24, Michel_D
wrote:Bonjour,
Je maintien aujourd'hui plusieurs base de données :
- Une base mère : une "coquille vide" dans laquelle il y a une
multitude de formulaires et de requêtes
- Une multitude de base filles qui sont des copies (copier coller ),
de la base mère dans lesquels des données (toujours le même
format),sont importées.
Ce système est devenu un vrai cauchemar car à chaque modifica tion
d'une requête ou d'un formulaire, je suis obligé de les dupli quer
dansla base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne
lefais pas).
D'où ma question :
Est il possible de dissocier formulaires-requêtes et données de tel
sorte qu'on puisse choisir la source des données à exploiter ?
S'ajoute à cela un contrainte : comme je travail en
multiutilisateur,il faut que plusieurs utilisateurs puissent se connecter en mêm e
temps, sur plusieurs sources différentes...
Avec un tel système, une modif sur un formulaire ou sur une req uête
serait répercutée sur l'ensemble des données à exploiter. Ce serait
lerêve...
J'espère que tout de même que cela peut devenir autre chose q u'un
rêve, car je passe un temps fou sur ces bases...
Je vous remercie d'avance. Si, par chance, vous pouviez apporter
uneréponse à ma question, vous me souveriez réellement la vie.
Tu recrée au démarrage les liaisons vers tes tables situées sur tes
bases filles, comme cela tu auras un frontal et x dorsals, par
contre il faudra être trés attentif lorsque tu vas modifier to n
frontal.- Masquer le texte des messages précédents -> >>> - Afficher le
texte des messages précédents -ça maaarche !!!!
J'ai utilisé la fonction fRefreshLinks (qui elle même est combi née
avec GetOpenFileName). Les tables sont relocalisée toutes seul co mme
des grandes.
Reste à tester cela en multiutilisateurs...
Les liens vers ces deux ensemble de fonctions génialissimes :
http://www.mvps.org/access/tables/tbl0009.htm->
fRefreshLinkshttp://www.mvps.org/access/api/api0001.htm-> GetOpenFileNam eJe ne pensais pas que cela pouvais être aussi simple (pensez bien à
séparer les deux codes dans deux modules différents).
Un grand merci,- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
En réalité, pas si génialissime que ça car deux utilisateurs ne
peuvent pas utiliser deux sources de données différentes à la fois.
Là, c'est un véritable problème étant donné que cela rend tout le
système inutile...
Y a t'il un moyen d'enregistrer les liens vers les tables sur le pos te
de travail plutôt que en dur, dans la base access elle-même ?
Tu lance ton frontal via un raccourci avec un paramêtre que tu réc upère
dans une procédure exécuté automatiquement au démarrage qui t' indique
sur quel(s) dorsal(s) tu doit lier tes table(s) et donc tu recrée si
besoin les liaisons vers tes tables, est-ce que c'est plus clair !
PS: Sur le même poste de travail tu peux avoir plusieurs raccourcis
pour aller sur différentes bases.- Masquer le texte des messages
précédents -- Afficher le texte des messages précédents -
J'ai bien compris le fonctionnement que tu décrit. C'est d'ailleurs à
peu près celui que j'utilise avec les deux fonctions. Cependant mon
problème n'est pas à ce niveau.
Mon problème est le suivant : une table ne peut pas être liée à deux
tables différentes en même temps selon l'utilisateur. Je pense qu'il
n'y a pas de solution à ce problème. Par conséquent, je suis en tr ain
d'étudier une solution de copie automatique des objets d'une base vers
les autres. Cela contourne pas trop mal mon soucis de mise à jour de
formulaire.
Merci pour vos aides. Elle m'ont été précieuse.- Masquer le texte des
messages précédents -- Afficher le texte des messages précédents -- Masquer le texte des
messages précédents -- Afficher le texte des messages précédents -
Merci pour cette réponse.
Cependant à ce moment je perd l'avantage d'avoir une et une seule base
à maintenir (les formulaires et les requêtes évoluent en parmance).- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -- Masquer le texte des me ssages précédents -
- Afficher le texte des messages précédents -
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fais
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveur. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
Bonjour,
C'est faisable en vbs et moi je prendrais la date de modification.
Set oFso = WScript.CreateObject("Scripting.FileSystemObject")
sFrontal = "TonFrontal"
sLocal = "Chemin local"
sServeur = "Chemin du serveur"
Set oFileLocal = oFso.GetFile(sLocal & "" & sFrontal)
Set oFileServeur = oFso.GetFile(sServeur & "" & sFrontal)
If oFileLocal.DateLastModified<>oFileServeur.DateLastModified Then
oFso.CopyFile sServeur & "" & sFrontal sLocal & "" & sFrontal Tr ue
End If
Set oFileServeur = Nothing
Set oFileLocal = Nothing
Set oFso = Nothing
Et pour lancer ton frontal
Set oShell = WScript.CreateObject("WScript.Shell")
sCmd = "MSAccess.exe """ & sLocal & "" & sFrontal & """" & " ;TonDo rsal"
oShell.run sCmd,3
Set oShell = Nothing
"J'ai-Du-Bois" a écrit dans le message denews:26e98
On 27 fév, 20:50, "Gilbert" wrote:Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fai s
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveu r. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
[...]
Gilbert,
Cette méthode a l'air géniale. Pourrais tu me donner des pistes pour
la création de cette exe ? Est ce que c'est un batch ou un programme
compilé ?
Merci d'avance,
Guillaume- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
C'est faisable en vbs et moi je prendrais la date de modification.
Set oFso = WScript.CreateObject("Scripting.FileSystemObject")
sFrontal = "TonFrontal"
sLocal = "Chemin local"
sServeur = "Chemin du serveur"
Set oFileLocal = oFso.GetFile(sLocal & "" & sFrontal)
Set oFileServeur = oFso.GetFile(sServeur & "" & sFrontal)
If oFileLocal.DateLastModified<>oFileServeur.DateLastModified Then
oFso.CopyFile sServeur & "" & sFrontal sLocal & "" & sFrontal Tr ue
End If
Set oFileServeur = Nothing
Set oFileLocal = Nothing
Set oFso = Nothing
Et pour lancer ton frontal
Set oShell = WScript.CreateObject("WScript.Shell")
sCmd = "MSAccess.exe """ & sLocal & "" & sFrontal & """" & " ;TonDo rsal"
oShell.run sCmd,3
Set oShell = Nothing
"J'ai-Du-Bois" <duboi...@gmail.com> a écrit dans le message denews:26e98 5a0-10a4-46be-957e-8327baea0396@h25g2000hsf.googlegroups.com...
On 27 fév, 20:50, "Gilbert" <ZZZZgilbert...@tiscali.fr> wrote:
Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fai s
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveu r. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
[...]
Gilbert,
Cette méthode a l'air géniale. Pourrais tu me donner des pistes pour
la création de cette exe ? Est ce que c'est un batch ou un programme
compilé ?
Merci d'avance,
Guillaume- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
C'est faisable en vbs et moi je prendrais la date de modification.
Set oFso = WScript.CreateObject("Scripting.FileSystemObject")
sFrontal = "TonFrontal"
sLocal = "Chemin local"
sServeur = "Chemin du serveur"
Set oFileLocal = oFso.GetFile(sLocal & "" & sFrontal)
Set oFileServeur = oFso.GetFile(sServeur & "" & sFrontal)
If oFileLocal.DateLastModified<>oFileServeur.DateLastModified Then
oFso.CopyFile sServeur & "" & sFrontal sLocal & "" & sFrontal Tr ue
End If
Set oFileServeur = Nothing
Set oFileLocal = Nothing
Set oFso = Nothing
Et pour lancer ton frontal
Set oShell = WScript.CreateObject("WScript.Shell")
sCmd = "MSAccess.exe """ & sLocal & "" & sFrontal & """" & " ;TonDo rsal"
oShell.run sCmd,3
Set oShell = Nothing
"J'ai-Du-Bois" a écrit dans le message denews:26e98
On 27 fév, 20:50, "Gilbert" wrote:Tu dis toi-même que "Ce système est devenu un vrai cauchemar car à chaque
modification d'une requête ou d'un formulaire, je suis obligé de les
dupliquer dans la base mère, ainsi que dans l'ensemble des base filles (en
l'occurence le travail est tellement long et fastidieux que je ne le fai s
pas)"
J'utilise cette méthode :
La base frontale sur le serveur et sur chaque poste de travail.
Au lieu d'ouvrir directement la base sur le poste de travail j'ouvre un
petit exe qui compare les dates de création du frontal sur le serveur et sur
le poste.
Si le frontal du poste n'est pas à jour, je copie le fichier du serveu r. Et
ensuite la base est ouverte par cet exe.
Une seule base à maintenir, la mise à jour est automatique sur tous les
postes.
--
Cordialement,
Gilbert
[...]
Gilbert,
Cette méthode a l'air géniale. Pourrais tu me donner des pistes pour
la création de cette exe ? Est ce que c'est un batch ou un programme
compilé ?
Merci d'avance,
Guillaume- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -