Discussion :

[pschmidtke]

Bonjour,

je voulais savoir s'il y a d'autres moyens pour diminuer la taille des fichiers mdb que la décompilation et le compactage ?

Merci d'avance pour vos réponses.

Peter

[M1000]

Mettre moins de données ...
Bon okay je

[pschmidtke]

rigolo...c'est la partie la moins lourde de la base. C'est les formulaires et le code, en gros le front end qui pèse.

[Fablondon]

Salut tu peux séparer le code de tes donnees si tu veux..... ++

[pschmidtke]

est-ce que pour faire ça je peux utiliser des chemins relatifs sous Access2000 et VB6 ? J'avais déjà essayé cette approche, mais dès qu'on migre rien ne marche plus.

[pschmidtke]

est-ce que quelqu'un a des idées ?

[=JBO=]

Bonjour,

Salut tu peux séparer le code de tes donnees si tu veux..... ++

Est-ce une application multi-utilisateurs ?

est-ce que pour faire ça je peux utiliser des chemins relatifs sous Access2000 et VB6 ? J'avais déjà essayé cette approche, mais dès qu'on migre rien ne marche plus.

Tu sais que la séparation [Application front-end] et [Base de données back-end] s'appuie sur l'utilisation de tables liées.
Une table liée "réside" dans l'application et "pointe" vers la table réelle placée dans le fichier contenant la base de données.

Les informations d'attache contenues dans les tables liées n'acceptent pas les chemins relatifs.

Quand on migre, on prévoit d'attacher à nouveau les tables dans l'environnement de production: c'est un préalable indispensable.
D'ailleurs Access nous fournit un assistant pour faciliter cette opération: Le gestionnaire de tables liées.

est-ce que quelqu'un a des idées ?

Dans le cas d'une application Access qui évolue quotidiennement (corrections, nouvelles fonctionnalités...), il devient très vite fastidieux d'attacher les tables à chaque nouveau déploiement.
Et c'est encore plus vrai quand:
* les tables attachées sont hébergées dans plusieurs base de données;
* les déploiements concernent plusieurs sites où les attaches sont différentes d'un site à l'autre.

Fatigué de tout ce bricolage, nous avons opté pour l'utilisation d'un lecteur réseau dont la lettre est immuable (par exemple Z: ) et qui existe aussi bien sur les PC utilisateurs que sur les PC de développement, quel que soit le site.

Le lecteur réseau des PC utilisateurs pointe sur un partage réseau qui contient les véritables bases de données.

Le lecteur réseau des PC de développement pointe sur un partage réseau qui contient les bases de données de tests/développement.

En plus, avec cette lettre de lecteur immuable (lecteur réseau ou lecteur logique créé via la commande DOS SUBST), il est assez simple d'emporter les bases de données sur un PC portable, même déconnecté (en effet, dans certaines conditions, les fonctionnalités de partage réseau sont indisponibles !).

OUI, un lecteur réseau c'est un peu lourd à mettre en place sur tous les PC de l'entreprise...
MAIS, les déploiements sont tellement simplifiés ! Et quel temps gagné !

-=-=-=-=-=-=-=-=-

Ça ne répond pas à la question initiale... faire maigrir une Application Access.

1ère piste: les images.

Tes formulaires / Etats comportent-ils des images ?

Access a tendance à gonfler démesurément quand il ingère une image.

Si c'est ton cas, il faut optimiser ces images avant de les insérer.
Par exemple en diminuant leur résolution, en les convertissant dans un format fichier peu gourmand (PNG).
Et surtout pas de OLE, juste le contrôle Picture.

Certes, c'est un travail un peu fastidieux. Mais j'ai pu faire maigrir des formulaires/états passant de 10 Mo à 2 Mo...

Le mieux si tu n'as pas envie d'optimiser, ou si tes images peuvent changer:
laisser les images dans des fichiers externes et les charger à la demande.

2ème piste: les commentaires.

Si tu as tendance à beaucoup commenter le code, fais disparaître tout ces commentaires.

3ème piste: fichier application MDE.

Essaie de créer un fichier .MDE théoriquement "optimisé" pour le déploiement.

4ème piste: combiner les 3 premières pistes.

[pschmidtke]

Merci d'abord pour ta réponse.

J'avais initialement réalisé la base avec des tables liées pour séparer les données du code, mais ce n'est pas stable lors de la migration, sachant que celle ci est possible. La solution que t'avais proposée ne marche pas, car je suis dans un grand organisme ou l'administration est incapable de faire ce genre de choix.

C'est quoi au juste le la différence entre un fichier MDE et MDB (à part la taille bien-sûr ?

Pourquoi le code implémenté sous VB est aussi lourd? Même après avoir décompilé il est encore lourd, sachant que si je regarde l'équivalent sous python le programme est tout petit.