Base programme énorme : gestion de photos externes ?

**mihego32** · 14/04/2024, 13h02

Bonjour à toutes et tous,

J'utilise beaucoup msAccess (Office 2019 Pro Plus) depuis 1993, comme développeur professionnel mais à la retraite depuis quelques années. Mes applications comprennent une base PROGramme et une base DATA contenant les tables locales liées à l'application. Le choix de la base DATA s'effectue via un outil personnel de sélection, avec paramétrisation des écrans (taille et position) pour chaque application PROG & DATA. Ce système fonctionne correctement depuis près de 15 ans.

Mon application TVfilms24 permet de noter les émissions que je souhaite enregistrer, avec divers détails comme les comédien(ne)s d'un film avec éventuellement une série de photos. Les photos sont stockées individuellement dans un répertoire différent de ceux des bases PROG et DATA. La table T_Comédiens contient e.a. strPréNom avec prénom et nom et blnPhoto pour indiquer si des photos sont associées. Une routine permet de combiner le nom avec l'adresse standard (la même pour tous) du répertoire des photos pour afficher à la demande la suite de photos du comédien. Cela fonctionne très bien. Donc AUCUNE photo JPG ou WEBP ou AVIF, etc, ni son chemin d'accès avec son nom, n'est stockée ni dans la base PROG ni dans la base DATA.

Le problème c'est que ma base PROG est énorme : 1 708 460 Ko (même après compactage) alors que toutes mes autres bases PROG font au maximum 3 000 Ko. Cette taille énorme pourrait être due au fait qu'Access, ni vu ni connu ni documenté, y stockerait du broll pour toutes ces photos. La base DATA ne fait que 2 096 Ko, tout-à-fait normal. En fait, il y a 1 645 photos pour un volume disque de 588 Mo, donc bien moins que la base PROG.

Quelqu'un peut-il m'aider à comprendre et résoudre le problème pour ramener la taille de la PROG à une taille normale ? Parce que cela a une FORTE incidence sur les back-ups. D'avance merci

**User** · 14/04/2024, 13h38

Bonjour,

...Une routine permet de combiner le nom avec l'adresse standard (la même pour tous) du répertoire des photos pour afficher à la demande la suite de photos du comédien.

Quel type de contrôle utilisez-vous pour afficher ces images (j'imagine affichées sur un formulaire) ?

Plus précisément, quelle technique utilisez-vous pour cela ?

Cdlt,

**EricDgn** · 15/04/2024, 11h26

Bonjour,

Commencer par créer une nouvelle base de données vide et ensuite l'utiliser pour recréer l'application: y lier les tables externes et y importer tous les autres objets de l'application (tables, requêtes, formulaires, macros, modules).

Ruban >> Données externes >> Nouvelle source de données >> A partir d'une base de données >> Access >> ...

Cela peut considérablement réduire la taille du fichier. Ne me demandez pas pourquoi, mais c'est beaucoup plus efficace que le compactage! Dernièrement chez moi 12 Gb > 7 Gb.

Bien cordialement.

**tee_grandbois** · 15/04/2024, 18h28

bonjour,

Envoyé par mihego32

Le problème c'est que ma base PROG est énorme : 1 708 460 Ko (même après compactage) alors que toutes mes autres bases PROG font au maximum 3 000 Ko. Cette taille énorme pourrait être due au fait qu'Access, ni vu ni connu ni documenté, y stockerait du broll pour toutes ces photos. La base DATA ne fait que 2 096 Ko, tout-à-fait normal. En fait, il y a 1 645 photos pour un volume disque de 588 Mo, donc bien moins que la base PROG.

le fait est que si la propriété Type image est défini à: "Partagé", Access va stocker l'image dans une table cachée (je ne sais pas laquelle mais visiblement ce n'est pas une des tables commençant pas MSys) et il fera une copie même si l'image a déjà été stockée : en gros il crée une copie de l'image à chaque fois sans chercher à savoir si elle existe déjà ; d'ailleurs on peut voir la liste si on clique sur la propriété "Image" de l'objet, une liste déroulante affiche toutes les images et celles qui ont été déjà affichées sont préfixés d'un nombre suivi d'un souligné puis le nom de l'image.

J'ai constaté ce problème il y a quelques années dans une de mes bases, et, comme l'a préconisé EricDgn, j'ai du tout réimporter dans une nouvelle base pour retrouver une taille plus conforme aux données stockées. Je ne suis donc pas étonné que la base de mihego32 puisse grossir en peu de temps.

L'ironie dans tout ça, c'est que le type image "Incorporé" ne stocke pas les données, contrairement à ce qui est indiqué dans l'aide Microsoft (ou alors j'ai mal lu ou bien bu ou c'est la traduction

) ...

Je viens de faire le test avec Access 365 en mettant dans 3 bases différentes la propriété type image :
- à "Incorporé" (0 en VBA) : ne stocke pas de données image
- à "Attaché" (1 en VBA) : ne stocke pas de données image
- à "Partagé" (2 en VBA) : est la plus gourmande puisque, après un affichage de 10 images, ma base est passée de 50Ko à 28Mo avec des images de 3Mo en moyenne

**mihego32** · 13/05/2024, 12h54

Salut à tous,

Mille excuses, je croyais recevoir un message lorsqu'une réponse était postée. Mais bernique ! C'est presque par hasard que je suis revenu lire mon message et ai constaté avec bonheur que j'avais des réponses et combien intéressantes : merci pour vos réponses, en particulier celle de tee_grandbois.

J'ai donc changé de "Partagé" à "Incorporé" le type d'image du champ qui permet de visualiser la 1ère photo du comédien sélectionné. J'ai fermé l'application puis travaillé un peu avec elle mais la taille n'a pas diminué... : 1.717.606 Ko !

J'ai donc créé une nouvelle base, récupéré tous les objets et rétabli les liens avec les tables et fait 2 constatations :
- la première, c'est que la nouvelle base ne fait plus que 2.688 Ko et c'était bien l'objet de mon appel à vos compétences : donc merci.
Dans la volumineuse base, j'ai regardé les tables cachées ou masquées. La seule qui a attiré mon attention est la table "MSysResouces" avec 1.796 lignes alors que mon dossier de photos n'en contient que 1.665 ; son premier champ a un nom curieux : un caractère en forme de trombone de bureau (trombone recourbé avec le code U+1F4CE) et son contenu montre ce trombone suivi de "(1)" ; en cliquant dessus, je visualise la photo. J'ai supprimé toutes les lignes de cette table et fermé la base qui reste de la même taille. J'ai via mon formulaire visualisé une photo mais rien ne s'est ajouté dans "MSysResouces". Je laisse à d'autres curieux ou futés, le plaisir de trouver la vraie cause de cet embonpoint.
- la deuxième, c'est que les objets importés ne sont pas vraiment les mêmes. Par exemple, les cases à cocher sont devenues des petits carrés bleu au lieu du carré blanc avec un "v". Ou bien la couleur de fond d'un formulaire est verte au lieu de brun, même si le libellé est le même dans la nouvelle et dans l'ancienne base : "Accent 6, Plus clair 80%". Ou encore, j'ai dû revoir toutes les requêtes sous-jacentes aux formulaires ou rapports, car Access avait ajouté "Expr...:" devant chaque variable. Bref une demi-journée de travail pour redevenir opérationnel avec la nouvelle base. Donc ce n'est certainement pas "MERCI" que je dis à Microsoft...

Bonne journée,

**tee_grandbois** · 13/05/2024, 14h53

bonjour,

La seule qui a attiré mon attention est la table "MSysResouces" avec 1.796 lignes alors que mon dossier de photos n'en contient que 1.665 ; son premier champ a un nom curieux : un caractère en forme de trombone de bureau (trombone recourbé avec le code U+1F4CE) et son contenu montre ce trombone suivi de "(1)" ; en cliquant dessus, je visualise la photo.

c'était un fichier masqué ! en effet, je n'avais pas coché "Afficher les objets masqués" dans les options de navigation, c'est bien dans MsysResources que sont stockées les images, en plusieurs exemplaires pour certains puisque, comme je l'expliquai, Access ne cherche pas à savoir si l'image est déjà stockée... on voit dans champ Name de la table les objets stockés plusieurs fois grâce au préfixe précédant le nom (ce qui explique ta différence par rapport à ton nombre de photos):

Nom : _0.JPG
Affichages : 61
Taille : 56,0 Ko

Nom : _0.JPG
Affichages : 61
Taille : 56,0 Ko

J'ai supprimé toutes les lignes de cette table et fermé la base qui reste de la même taille.

ce n'est pas automatique il faut compacter et réparer
Attention: il y avait également un enregistrement de type thmx (thème office de la base) qu'il ne fallait pas supprimer

Je laisse à d'autres curieux ou futés, le plaisir de trouver la vraie cause de cet embonpoint.

c'est bien ce fichier ressource qui en est la cause

**EricDgn** · 13/05/2024, 17h08

"Access avait ajouté "Expr...:" devant chaque variable"

Cela provient du fait que les tables liées n'avaient pas été attachées avant d'effectuer l'import des autres objets de l'ancienne base (tables, requêtes, formulaires, etc.) dans la nouvelle base.

**mihego32** · 15/05/2024, 10h51

Envoyé par tee_grandbois

Attention: il y avait également un enregistrement de type thmx (thème office de la base) qu'il ne fallait pas supprimer

L'enregistrement "thmx" a été d'office recréé.

Merci EricDgn, observation très pertinente : d'abord attacher les tables avant d'importer les objets requêtes, formulaires, états...

Puis-je indiquer que le problème est résolu et la discussion close ?

NB : l'option "S'abonner à la discussion et me notifier des modifications" est activée mais je ne reçois aucune notification.