{Access} liaison Dorsale/frontale
Résolu/Fermé
Co52
Messages postés
78
Date d'inscription
dimanche 1 novembre 2009
Statut
Membre
Dernière intervention
8 octobre 2016
-
29 nov. 2009 à 19:23
Co52 Messages postés 78 Date d'inscription dimanche 1 novembre 2009 Statut Membre Dernière intervention 8 octobre 2016 - 1 déc. 2009 à 16:39
Co52 Messages postés 78 Date d'inscription dimanche 1 novembre 2009 Statut Membre Dernière intervention 8 octobre 2016 - 1 déc. 2009 à 16:39
A voir également:
- {Access} liaison Dorsale/frontale
- Caméra frontale telephone portable ✓ - Forum Mobile
- Access appdata - Guide
- Camera frontale ne fonctionne pas - Forum Huawei
- Liaison excel introuvable ✓ - Forum Excel
- Exemple base de données access à télécharger gratuit ✓ - Forum Logiciels
25 réponses
Co52
Messages postés
78
Date d'inscription
dimanche 1 novembre 2009
Statut
Membre
Dernière intervention
8 octobre 2016
3
1 déc. 2009 à 14:19
1 déc. 2009 à 14:19
ok c'est fait, j'ai créé une table locale et j'ai modifié mon code. Si j'ouvre mon programme ca marche.
donc si j'ai tout compris, en fait, si le chemin change, il me suffit d'ouvrir la table et de modifier le chemin dans ma table.
Encore 2 points a voir avec toi au sujet de ce code :
1 - Je suis sous access 2007 donc mon fichier et en accdb.
tu parles de créer un .mde, j'ai vu qu'en fait c'était une base ou les codes vba etaient compile et les tables cachés mais les tables étant dans une base indépendantes, lequels dois-je mettre en mde et comment je fait.
De plus, pour protéger un tant soit peu ma base, dans les options d'access je n'ai pas demandé l'affichage du volet de navigation et je pense que les utilisateurs ne sauront pas les changer.
2 - Ma base étant utilisée de façon ponctuelle pour des bourses aux vêtements, à chaque nouvelle bourse, j'ai créé un macro qui remet à zéro la plupart de mes tables.
Les clefs que j'utilise pour établir les relations sont principalement des numéro auto et restent transparent pour l'utilisateur.
J'ai par contre deux tables très importantes (je dirai les principales) où l'utilisateur voit et utilise la clef :
la première et celle des déposants où la clef n'est pas un numéro auto mais une saisie manuelle donc aucun soucis.
la seconde et celle des acheteurs où la clef est bien un numéro automatique. L'utilisateur voit cette clef parce qu'elle peut lui servir pour revenir plus tard sur un acheteur. Malheureusement, lorsque je remets à zéro ma base, si sur la première bourse j'ai eu 350 acheteurs, à la bourse suivante, le premier acheteur aura le numéro 351 et non le 1 comme je le voudrai.
Sur mon précédent programme que j'avais créé, comme je n'avais pas scindé ma base en deux, à chaque fois que je fermer mon programme, au compactage, les numéros automatiques ce remettaient à jour. Le problème c'est que même si j'ai demandé le compactage de mes 2 bases à la fermeture, la base dorsale n'étant pas réellement ouverte, elle ne se compacte pas. Ne serait-il pas possible au tout début du code que tu viens de me donner de demander d'ouvrir et de refermer la base dorsale puisqu'on a son chemin dans la table locale ou plus simplement créé une ligne demandant le compactage de cette base.
Encore un grand merci pour ton aide
donc si j'ai tout compris, en fait, si le chemin change, il me suffit d'ouvrir la table et de modifier le chemin dans ma table.
Encore 2 points a voir avec toi au sujet de ce code :
1 - Je suis sous access 2007 donc mon fichier et en accdb.
tu parles de créer un .mde, j'ai vu qu'en fait c'était une base ou les codes vba etaient compile et les tables cachés mais les tables étant dans une base indépendantes, lequels dois-je mettre en mde et comment je fait.
De plus, pour protéger un tant soit peu ma base, dans les options d'access je n'ai pas demandé l'affichage du volet de navigation et je pense que les utilisateurs ne sauront pas les changer.
2 - Ma base étant utilisée de façon ponctuelle pour des bourses aux vêtements, à chaque nouvelle bourse, j'ai créé un macro qui remet à zéro la plupart de mes tables.
Les clefs que j'utilise pour établir les relations sont principalement des numéro auto et restent transparent pour l'utilisateur.
J'ai par contre deux tables très importantes (je dirai les principales) où l'utilisateur voit et utilise la clef :
la première et celle des déposants où la clef n'est pas un numéro auto mais une saisie manuelle donc aucun soucis.
la seconde et celle des acheteurs où la clef est bien un numéro automatique. L'utilisateur voit cette clef parce qu'elle peut lui servir pour revenir plus tard sur un acheteur. Malheureusement, lorsque je remets à zéro ma base, si sur la première bourse j'ai eu 350 acheteurs, à la bourse suivante, le premier acheteur aura le numéro 351 et non le 1 comme je le voudrai.
Sur mon précédent programme que j'avais créé, comme je n'avais pas scindé ma base en deux, à chaque fois que je fermer mon programme, au compactage, les numéros automatiques ce remettaient à jour. Le problème c'est que même si j'ai demandé le compactage de mes 2 bases à la fermeture, la base dorsale n'étant pas réellement ouverte, elle ne se compacte pas. Ne serait-il pas possible au tout début du code que tu viens de me donner de demander d'ouvrir et de refermer la base dorsale puisqu'on a son chemin dans la table locale ou plus simplement créé une ligne demandant le compactage de cette base.
Encore un grand merci pour ton aide
blux
Messages postés
26507
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
4 décembre 2024
3 317
1 déc. 2009 à 15:18
1 déc. 2009 à 15:18
donc si j'ai tout compris, en fait, si le chemin change, il me suffit d'ouvrir la table et de modifier le chemin dans ma table.
Voui, c'est juste qu'access va grogner AVANT que tu ne puisses modifer la table 'constantes' si le chemin a changé, mais il suffira de modifier cette table, clôturer access et le relancer.
1 - C'est bien sûr ta base frontale que tu dois mettre en MDE, avec le menu 'outils/utilitaires bases de données' ou un truc approchant (je n'ai pas access 2007 chez moi).
Fais bien attention de conserver une copie de ta base AVANT de la mettre en MDE, car après cette manipulation, plus de retour arrière possible.
2 - Pas facile de compacter une base ouverte depuis une autre.
On peut par contre aller sur la 'dorsale' et dans le menu outils/options/onglet général, cocher "compacter la base à la fermeture", ce qui aura pour effet de compacter la base lorsque le dernier utilisateur connecté dessus la quitte.
Quelques infos sur la protection d'une appli access :
https://forums.commentcamarche.net/forum/affich-144030-password#9
Voui, c'est juste qu'access va grogner AVANT que tu ne puisses modifer la table 'constantes' si le chemin a changé, mais il suffira de modifier cette table, clôturer access et le relancer.
1 - C'est bien sûr ta base frontale que tu dois mettre en MDE, avec le menu 'outils/utilitaires bases de données' ou un truc approchant (je n'ai pas access 2007 chez moi).
Fais bien attention de conserver une copie de ta base AVANT de la mettre en MDE, car après cette manipulation, plus de retour arrière possible.
2 - Pas facile de compacter une base ouverte depuis une autre.
On peut par contre aller sur la 'dorsale' et dans le menu outils/options/onglet général, cocher "compacter la base à la fermeture", ce qui aura pour effet de compacter la base lorsque le dernier utilisateur connecté dessus la quitte.
Quelques infos sur la protection d'une appli access :
https://forums.commentcamarche.net/forum/affich-144030-password#9
Co52
Messages postés
78
Date d'inscription
dimanche 1 novembre 2009
Statut
Membre
Dernière intervention
8 octobre 2016
3
1 déc. 2009 à 16:20
1 déc. 2009 à 16:20
Pour la protection avec le .MDE, je vais étudier la question tranquillement.
Pour ce qui est du compactage, j'ai déjà cocher l'option de compacter à la fermeture mais rien ne se passe. J'ai testé plusieurs fois et la numérotation de ma table acheteurs ne se remet jamais à zéro.
J'ai testé manuellement l'opération c'est à dire qu'à l'ouverture de mon programme, juste avant que le code ne soit lancé, j'ai ouvert ma table dorsale, j'ai lancé un compacte et je l'ai refermé, j'ai ensuite vérifier ma table acheteurs et la numérotation commencée bien au numéro 0.
D'où ma question, ne peut on pas automatiser cette opération dans le code que tu m'as fait mais en tout début de code.
Hier je t'avais dit que j'avais deux autres questions, ce problème de compactage est la première mais je la traite ici parce que je pense que la manipulation doit entrer dans le même code. Je vais traiter la seconde dans un autre post car elle n'a aucun rapport. Pourras-tu y jeter un coup d'œil peut être pourras tu encore m'aider
Une fois de plus je te remercie de ton aide
Pour ce qui est du compactage, j'ai déjà cocher l'option de compacter à la fermeture mais rien ne se passe. J'ai testé plusieurs fois et la numérotation de ma table acheteurs ne se remet jamais à zéro.
J'ai testé manuellement l'opération c'est à dire qu'à l'ouverture de mon programme, juste avant que le code ne soit lancé, j'ai ouvert ma table dorsale, j'ai lancé un compacte et je l'ai refermé, j'ai ensuite vérifier ma table acheteurs et la numérotation commencée bien au numéro 0.
D'où ma question, ne peut on pas automatiser cette opération dans le code que tu m'as fait mais en tout début de code.
Hier je t'avais dit que j'avais deux autres questions, ce problème de compactage est la première mais je la traite ici parce que je pense que la manipulation doit entrer dans le même code. Je vais traiter la seconde dans un autre post car elle n'a aucun rapport. Pourras-tu y jeter un coup d'œil peut être pourras tu encore m'aider
Une fois de plus je te remercie de ton aide
blux
Messages postés
26507
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
4 décembre 2024
3 317
1 déc. 2009 à 16:36
1 déc. 2009 à 16:36
Je viens de jeter un oeil, il semblerait que l'on puisse compacter une base en VBA en travaillant sur le moteur jet avec DBEngine.CompactDatabase
Mais ça demande une base à compacter qui soit fermée, pour la recopier ensuite sur un nouveau nom, donc moyennement intéressant dans le cas qui nous préoccupe.
Je crois qu'il va falloir habituer les vendeurs aux numéros uniques non réinitialisés :-)
Mais ça demande une base à compacter qui soit fermée, pour la recopier ensuite sur un nouveau nom, donc moyennement intéressant dans le cas qui nous préoccupe.
Je crois qu'il va falloir habituer les vendeurs aux numéros uniques non réinitialisés :-)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Co52
Messages postés
78
Date d'inscription
dimanche 1 novembre 2009
Statut
Membre
Dernière intervention
8 octobre 2016
3
1 déc. 2009 à 16:39
1 déc. 2009 à 16:39
OK, je te remercie encore beaucoup pour le coup de main et pour la patience que tu as eu avec moi pour mon problème.
Je t'attends sur mon autre post et cloture celui la
Je t'attends sur mon autre post et cloture celui la