Discussion :

[Golard]

Bonjour,

Je dispose d'un fichier Access (.mdb) qui contient à la fois les données (base de données d'une quinzaine de tables) et l'interface utilisateur (nombreux formulaires, requêtes, états, macros...).

Je désire faire évoluer l'interface utilisateur.

Pour cela je vais devoir "immobiliser" le fichier afin qu'il n'y ait pas de mise à jour de la base pendant mon intervention sur l'interface.

Quel est selon vous la meilleure méthode:

1. Simplement prévenir de l'intervention (par email) et demander de ne pas faire de mise à jour ?
2. Remplacer le .mdb par un autre qui affiche uniquement un écran "en maintenance" ?
3. Existe-t'il en Access 2007 une façon de dissocier la base et l'application ?

La 1ère méthode permet la consultation de la base pendant l'intervention.
La 2ème méthode permet de s'assurer qu'aucune mise à jour de la base ne sera faite pendant l'intervention.
La 3ème méthode serait l'idéal, mais est-ce possible sans y passer des heures de migration...?

Merci d'avance de me faire profiter de votre expérience en la matière !

Pour info: La base a été développée sous Access 2000 et mon environnement de développement est actuellement Access 2007

[madefemere]

Bonjour,

La meilleure façon est de séparer (scinder) ta base en 2 (frontale et dorsale) comme on dit où dans l'une tu as tes données et dans l'autre tu as tes requêtes, formulaires, états et modules.
Comme ça, si tu as besoin de modifier ton interface, tu n'as pas besoin de demander aux utilisateurs d'arrêter de travailler.
Il y a ce TUTO sur DVP qui explique de long en large comment faire cela et gérer automatiquement la connexion.


Cordialement,

[Golard]

Merci madefemere pour ta réponse documentée !

Dans un premier temps, pour ma première modification, je pense utiliser la méthode 2 (rendre indisponible la base en la remplaçant par une factice).

Ensuite je compte étudier de prêt ta proposition (et faire bien sur quelques tests) avant de passer la base "scindée" en production, compte tenu de l'importance des données contenue dans la base pour l'entreprise.

Etant depuis peu responsable de nombreuses bases, je vais devoir étudier et faire valider la valeur ajoutée de la séparation des données et de l'interface.
Une fois en place, il faudra que ce soit "transparent" pour l'utilisateur (je vais regarder de très prêt les problèmes de connexion dont tu parles).

Avant de marquer comme résolu cette discussion, peux-tu répondre à quelques questions supplémentaires ?

* De mémoire, Access n'était pas considéré comme une base "pro" et stable (dans les années 90), cela a-t'il changé depuis access 2007 ?
* Dans le cas où Access n'est toujours pas considéré comme stable pour de grosse bases, est-il établi que le fait de scinder la base stabilise les données ?

Concernant ma base, il s'agit aujourd'hui d'un fichier .mdb placé sur un réseau (et utilisé par plusieurs utilisateurs).
Je ne souhaite pas changer radicalement les habitudes d'installation/utilisation.
Du coup, je ne souhaite pas installer la partie formulaires, requêtes, macros... en local sur le poste.
J'envisage de placer en réseau les 2 fichiers: un fichier .mdb avec le même nom que le nom actuel (le fichier avec formulaires, requêtes, macros...) et le deuxième qui contiendrait juste les tables.

* Cette solution (base scindée, mais les 2 fichiers en réseau côte à côte) est-elle viable ? Ou va-t'elle à l'encontre de ta solution ?

MERCI d'avance pour le temps que tu passeras à me lire et me répondre !

[madefemere]

Bonjour,

* De mémoire, Access n'était pas considéré comme une base "pro" et stable (dans les années 90), cela a-t'il changé depuis access 2007 ?
* Dans le cas où Access n'est toujours pas considéré comme stable pour de grosse bases, est-il établi que le fait de scinder la base stabilise les données ?

"Pro" ou "pas pro", pour moi chacun a sa façon de voir.
Cela dépend effectivement de comment est montée l'application et QUI l'a montée. N'importe quelle application pour moi dépend de la personne qui l'a faite.
Il faut lire les caractéristiques d'Access pour voir ce qu'on peut faire avec. Pour moi l'essentiel est qu'une base Access est limitée à 2 Go. Ta base fais 1Go, je ne pense pas que ça posera de gros problème.
Si tu as une vingtaine d'utilisateurs répartis en plusieurs endroits connectés en même temps, cela pourrait être limite. Cela parce que Access n'est pas un système de gestion de base de données complète. En réseau, Access rapatrie toutes les données et traite après. Cela charge le réseau et la qualité du réseau peut donc avoir une influence sur ton application.
Stabilité, qu'est-ce qu'on entend par stable ?? J'ai des applications sous Access montées à l'arrache et qui fonctionnent depuis assez longtemps sans aucune maintenance. Donc...
Il y a beaucoup de discussion sur le sujet sur le site et les avis sont toujours d'actualités je pense.

Concernant ma base, il s'agit aujourd'hui d'un fichier .mdb placé sur un réseau (et utilisé par plusieurs utilisateurs).
Je ne souhaite pas changer radicalement les habitudes d'installation/utilisation.
Du coup, je ne souhaite pas installer la partie formulaires, requêtes, macros... en local sur le poste.
J'envisage de placer en réseau les 2 fichiers: un fichier .mdb avec le même nom que le nom actuel (le fichier avec formulaires, requêtes, macros...) et le deuxième qui contiendrait juste les tables.

* Cette solution (base scindée, mais les 2 fichiers en réseau côte à côte) est-elle viable ? Ou va-t'elle à l'encontre de ta solution ?

Elle est viable comme toute chose, mais l'inconvénient de n'avoir qu'un seul interface sur le réseau utilisé par plusieurs personnes, c'est qu'il se pourrait que si l'un des utilisateurs crashe l'interface, personne ne peut travailler.

Cordialement,

[Golard]

Merci pour tes précisions !

Je suppose à ta dernière remarque

(...)
Elle est viable comme toute chose, mais l'inconvénient de n'avoir qu'un seul interface sur le réseau utilisé par plusieurs personnes, c'est qu'il se pourrait que si l'un des utilisateurs crashe l'interface, personne ne peut travailler.
(...)

que ce ne sera de toute façon pas pire que lorsqu'il n'y a qu'un unique fichier .mdb !

Je n'ai rien loupé ?

Je flague résolu (et t'octroie un +1)