Discussion :

[Mors_Ubyte]

Bonjour,
Dans un Formulaire, lors de l'incorporation d'une image dans un contrôle de type "objet OLE", je souhaiterais que la taille de l'objet soit limitée.
Merci de me donner le paramêtre ou la procédure qui permet de limiter la taille des objets importés.

Après recherche dans la FAQ et sur le forum je n'ai pas trouver le sujet.

[stigma]

Il est préférable de traiter les images dans un dossier. Si tu utilises OLE pour stocker des images, ta base va exploser rapidement.
J'ai fait une appli pourles employés de la boite (458 photos de 400 pixels de large). la base frontale fait 2,4 M° et la base dorsale 700 K°. ces valeurs parlent d'elles-même.
Le sujet a été traité sur ce site.

[=JBO=]

Bonjour Mors_Ubyte et stigma !

Mors_Ubyte pour t'aider par rapport à ton objectif de «limiter la taille de l'objet», je voudrais t'apporter des informations utiles.

Dans une table d'une base MDB, on utilise un type de champ particulier pour stocker des données volumineuses sous leur forme binaire: on parle de champ BLOB (binary long object).
Ce type de champ est parfaitement maîtrisé par quiconque y place des données directement, via une bibliothèque d'accès aux données (DAO ou ADO).

En revanche, avec Access on perd la maitrise de ce type de champ.
En fait, Access accapare le type de champ BLOB pour lui substituer nommément le type de champ Objet OLE qui est lu ou écrit, dans un formulaire au moyen d'un contrôle OLE, ou dans une feuille de données, par certaines commandes spéciales du menu Edition (je crois ).

Pour résumer, on pourrait dire que:

un champ Objet OLE est une utilisation particulière d'un champ BLOB pour assurer la persistance de données/document produits par un serveur OLE, dans le contexte d'une infrastructure COM.

Un contrôle OLE ne se contente pas d'écrire une copie d'un fichier (document) dans un champ BLOB.
Un contrôle OLE est un composant client OLE dans l'infrastructure COM de Windows.
Il travaille en prise directe avec un serveur COM OLE.
Il présente les données dans un ou plusieurs formats "standards" tout en conservant les données au format natif utilisé par le serveur COM.
Et tout ça est stocké dans le champ Objet OLE: type du document OLE, identifiant du serveur, copies des données dans n format standards qui ne sont pas optimisés, et enfin copie des données dans le format natif.
Il n'est pas rare que le "stockage Objet OLE" occupe 10 fois l'espace qui serait requis pour le "stockage BLOB" du même document !

Voilà pourquoi il faut éviter d'utiliser un contrôle OLE directement lié à un champ Objet OLE pour une table qui comporterait de nombreux enregistrements.

En revanche, on peut raisonnablement envisager de stocker directement des données BLOB dans un fichier MDB:
(+) on maîtrise la taille des données,
(-) mais on perd le bénéfice de la prise en charge immédiate du contenu par un contrôle OLE,
(-) mais il faut programmer l'insertion/extraction des données vers/à partir du champ BLOB.

Aussi, pour des besoins de stockage d'images nombreuses et/ou volumineuses, il est fréquemment conseillé de les stocker directement dans le système de fichiers, comme le dit stigma:

Il est préférable de traiter les images dans un dossier. Si tu utilises OLE pour stocker des images, ta base va exploser rapidement.
J'ai fait une appli pour les employés de la boite (458 photos de 400 pixels de large). la base frontale fait 2,4 M° et la base dorsale 700 K°. ces valeurs parlent d'elles-même.
Le sujet a été traité sur ce site.

[Mors_Ubyte]

Merci pour vos réponse, voila qui m'a éclairé sur le sujet.
En complément à la réponse de =JBO=, je suis aller voir le lien suivant :

http://www.developpez.net/forums/d40...chier-binaire/