Discussion :

[popolitto]

Bonjour,
J'ai développé une application access qui est utilisée par plusieurs personnes (runtime).
La base de données access se situe sur un réseau.
Cette application gère des chantiers, commandes, factures,...
Certaines tables comprennent pas mal d'enregistrements (la plus grosse 15000 environ).
D'autres comprennent des champs "texte long", des images pdf ...

Cette application tourne bien depuis presque un an, je fais régulièrement des mise à jour et j'envisage d'y ajouter d'autres fonctionnalités...

Le problème auquel je suis confronté est que la base de données est devenue volumineuse (un peu plus de 2 G).
L'application est devenue instable pour ne pas dire à certains moments bloquée.
J'ai bien entendu fait un compactage qui n'a presque rien fait.

J'ai tous les utilisateurs sur le dos, je ne sais pas quoi faire à ce jour.
Vers quoi puis-je m'orienter pour trouver une solution la plus rapide.
J'ai vu qu'il était possible de migrer la base vers du sql, si c'est la cas, il faudrait que je trouve un tuto pour m'aider car je ne maîtrise pas bien ceci.

Bref, je m'adresse à vous pour essayer de trouver une solution même provisoire.

Merci

[tee_grandbois]

bonsoir,
la première manipulation consiste à séparer (ou fractionner) les tables des autres objets (Requêtes, IHM, Formulaires, Etats, Modules, Macros) de manière à avoir une base dorsale (contenant les tables) et une base frontale (pour les autres objets). C'est d'ailleurs la conception classique d'une base de données Access.
Ensuite il faut attacher les tables dans la base frontale pour les rendre accessibles. Il est aussi possible de créer plusieurs base dorsales ce qui permet d'aller bien au-delà de la limite des 2Go.

Voici le lien d'un tuto permettant de gérer les liaisons : http://jdgayot.developpez.com/tutori...cess/liaisons/

[bertiny]

Bonsoir
En complément avec ce que le confrère Tee_grandbois a dit, Etant donné que la capacité des bases de données access est de 2Go (de manière théorique par fichier mdb ou mde ), alors cette base de données est déjà pleine
Il est mieux de
- ne pas stocker les images dans les tables mais dans les dossiers externes et d'y accéder en Inscrivant simplement le chemin d'accès dans la table et les afficher dans des contrôles images (quand cela est nécessaire). Ce qui est sur c'est que cette base de données grandie aussi vite à cause des images que tu stockes dans les tables. Il faut donc reprendre la dorsale et la restructurer ainsi.
- configurer le compactage automatique lors de la fermeture de la base de données.
Il pourrait y avoir mieux que ce que je t'ai proposé. C'est ma modeste contribution.

Cordialement.

[loufab]

Bonjour,

Plusieurs personnes, volumineuse...

Une fois que tu auras séparé les tables de l'ihm, passe sur MS SQL Server express. C'est un autre moteur de base de données plus adapté à ton cas.

Cordialement,

[popolitto]

Merci d'avoir répondu si vite, je pense qu'une telle réactivité est primordial dans un forum.
Les gens ont vraiment le sentiment d'être soutenus et aidés dans leurs déboires.

Pour revenir au sujet, je fais une réponse groupée à l'attention de chacun d'entre vous.
("tee_grandbois") La base de données est dissociée des autres objets, en fait elle se situe sur un serveur et on y accède par le réseau (si j'ai bien compris c'est la dorsale).
Quant aux autres objets, ils se situent dans une base applicative que chaque utilisateur possède et qui tourne en runtime (frontale?).
Je pense que le fait de créer plusieurs base dorsales répondrait effectivement à mon problème, mais au regard du tuto cela me semble compliqué (je ne suis pas un spécialiste en la matière), n'y a-t-il pas un moyen plus simple d'y arriver?

("bertiny") Je vais faire un essai en supprimant toutes les images (il n'y en a pas des masses mais sait-on jamais) et vérifier l'impact en contrôlant le volume de la base.

("loufab") J'ai effectivement croisé cette solution sur le web, mais je ne sais pas comment faire.
Où trouver "MS SQL Server express", comment transférer les données des tables à partir d'access...
Existe-t-il un tuto dans ce sens?

Avec tout vos éléments, j'espère trouver la solution la plus adaptée sans trop démonter mon application.

Merci encore et Cordialement

[tee_grandbois]

bonsoir,

("tee_grandbois") La base de données est dissociée des autres objets, en fait elle se situe sur un serveur et on y accède par le réseau (si j'ai bien compris c'est la dorsale).

dans ce cas laisse tomber le tuto si tu connais le fonctionnement
Il te suffit de créer les bases de données et exporter les tables à ta convenance et ensuite les supprimer de la base d'origine puis de la compacter.
Pour finir, depuis la base frontale, il suffit d'attacher les tables des nouvelles bases (Gestionnaire des tables liées)

[loufab]

Bonjour,

Pour Ms SQL serveur express, Google donne le lien : https://www.microsoft.com/fr-fr/sql-...itions-express

Il existe un utilitaire de conversion ACCESS > SQL server.

Là encore Google est ton ami : https://docs.microsoft.com/en-us/sql...ss-accesstosql

Il faut attacher les tables SQL comme on le fait avec les tables ACCESS. On peut continuer à utiliser les mêmes requêtes, DAO et ADO.

Il y a peut-être un travail à faire sur les documents attachées, les champs multi valués et autres spécificités JET.

Cordialement,

[popolitto]

Bonjour,
C'était bel et bien les images qui prenaient énormément de place dans la base de données dorsale. Ce champ était un champ OLE et le contenu pouvait être tout type de fichiers (surtout des pdf).
J'ai donc modifié la structure de la table en remplaçant le type du champ "OLE" par "Pièce jointe" qui permet d'insérer plusieurs fichiers séparés.
J'ai du donc rapatrier toutes les images existantes dans ce nouveau champ, la base s'en est trouvée donc fortement diminuée.
Faute de temps, pour l'instant je pense que je vais en rester là, je surveillerai attentivement la base.
Pour l'avenir (proche), je vais réfléchir: soit une architecture multi base, soit sql.

Dans tous les cas, vos réponses m'ont été très précieuses et je vous remercie encore de votre réactivité.
Je pense vous solliciter prochainement...

Cordialement