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
Version imprimable
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
Mettre moins de données ...
Bon okay je :arrow:
:) 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.
Salut tu peux séparer le code de tes donnees si tu veux..... ++
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.
est-ce que quelqu'un a des idées ?
Bonjour,Est-ce une application multi-utilisateurs ?Citation:
Envoyé par Fablondon
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.Citation:
Envoyé par pschmidtke
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.
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.Citation:
Envoyé par pschmidtke
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... 8O :)
Le mieux si tu n'as pas envie d'optimiser, ou si tes images peuvent changer:
:fleche: 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. :lol:
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.
Si tu ne modifie rien à la DB, le compactage ne sert à rien.
Chaque fois que tu intervient en modification des formulaires, états, ... la taille de la DB augmente assez bien, lors du compactage, la taille diminue.
L'augmentation de taille liée aux données est moins spectaculaire.
La différence entre un MDB et un MDE c'est expliqué dans la FAQ http://access.developpez.com/faq/?page=General#mde
je ne peux pas appeler les fonctions utilisé sous Access à partir de modules externes ou quelque chose comme ça (toujours avec l'idée d'avoir des chemins relatifs)? Sinon merci pour le lien sur les .MDE.
est-ce que c'est possible par une approche programmation de lier des tables avec des chemins relatifs sur une autre base en Access 2000? Idem pour des modules en VB qu'on pourrait externaliser ?
Bonjour,As-tu cherché dans la FAQ ?Citation:
Envoyé par pschmidtke
FAQ: Rétablir les liaisons des tables liées après déplacement d'une base fractionnée http://access.developpez.com/faq/?pa...#RetablLienTbl
Pardon, mais pour moi ce n'est pas assez précis:Citation:
Envoyé par pschmidtke
* VB c'est VB6 ou VBA Access ?
* Externaliser ? Tu veux dire créer un composant ou une bibliothèque ?
VB6:
Tu peux créer une DLL ActiveX (cf. le Forum Visual Basic).
VBA Access:
Tu peux créer un fichier MDA. Le A c'est pour add-in, c'est à dire un complément d'Access.
Créer une bibliothèque de code pour Access:
(1) créer un fichier MDB dans lequel on copie tous les modules de code qui feront partie de la bibliothèque,
(2) donner un nom à la bibliothèque qui servira à la désigner dans l'explorateur d'objets et à préfixer les noms des procédures, classes et Types qu'elle contient:
* dans l'IDE, exécuter le commande de menu [Outils | Propriétés de...],
* dans la boite de dialogue [Propriétés du projet], sélectionner l'onglet [Général] et renseigner le champ [Nom du projet]
(3) Compiler et enregistrer le projet.
(4) Refermer le projet/fichier MDB et modifier l'extension du fichier en MDA.
(5) Pour utiliser la bibliothèque dans un projet, référencer le fichier MDA.
Lorsqu'un fichier MDB qui référence une bibliothèque MDA est déployé sur un PC, Access est capable de rafraîchir automatiquement la référence selon un certain nombre de conditions. Le plus simple est de conserver dans le même répertoire (dossier) le fichier MDB et ses bibliothèques MDA.
Citation:
Envoyé par Aide en ligne
merci JBO je vais voir tout ça
Tiens je pensais (d'apres ce que j'avais lu sur la doc d'Access) qu'il etait preferable d'utiliser des objets OLE que des images directement dans la base de donnees... qu'en est-il? J'ai des petits schemas sous Excel que j'ai mis dans ma base, est-ce qu'il vaut mieux que j'en fasse des images et sous quel format?
Pourquoi un Document OLE incorporé prend-il plus de place qu'une image ?Citation:
Envoyé par catoucat
Un document est "matérialisé" par des données "natives", produites par le logiciel qui a créé ce document.
Traditionnellement, la "conservation" des données natives est assurée par le système de fichiers de l'ordinateur.Par exemple:
* document=[Classeur Excel],
* logiciel=[Application Excel],
* données natives=[fichier XLS]
Une Application Serveur OLE est un logiciel qui est capable (entre autres) de confier un document à un Container OLE.
Le Container OLE est capable (entre autres) de stocker les données natives afin de les conserver, de les "transporter".
En général, le Serveur OLE fournit aussi au Container des données supplémentaires qui servent à "présenter superficiellement" le document, afin d'en afficher une image dans le Container.
Les données supplémentaires de représentation sont dans un ou plusieurs formats "standards": métafile, DIB ou bitmap. Les données DIB, bitmap ne me semblent pas optimisées.
Donc, le Container OLE stocke:
* les données natives,
* un jeu de données de présentation non optimisées (parfois plusieurs formats).
Le tout est nécessairement plus gros qu'une unique image optimisée.
Cependant, durant l'opération d'insertion d'un Document OLE dans un container, il est possible de ne conserver qu'un seul format de présentation, sans données natives. Ainsi le volume de données peut être limité, mais on perd la possibilité de modifier le document avec son application d'origine.
Dans Access, le contrôle [Cadre d'objet {in]dépendant] est un Container OLE.
Il assure le stockage des données (natives et/ou présentation):
* soit dans un champ de BD (contrôle dépendant),
* soit dans un formulaire ou un état (contrôle indépendant).
Document OLE Excel avec données natives=plusieurs MoCitation:
Envoyé par catoucat
Picture (image métafile) du même document Excel (métafile)=probablement moins de 200 Ko
Pour les images bitmap, OLE effectue des conversions vers les formats standards.
Eviter de stocker les images 24 bits dans un container OLE.
Le mieux (pour OLE) c'est le format BMP 256 couleurs (8bits) compressé RLE.
Sinon, pour les images 24 bits et les formats "non standards OLE", il est plus économe de stocker les données binaires d'une image au format PNG ou JPEG.
Mais là, pas d'OLE et il faudra tout gérer "à la main".