Problème d'empaquetage de la base dorsale avec la base frontale

[Julie!!!]

Bonjour à tous,

J’ai quelques questions sur le runtime, bien que l’excellent tutoriel de JP Ambrosino m’a évité bien des écueils ! Un grand merci !

Ma base de données est un ensemble de 3 bases access 2003 :
1. Une bd Frontale
2. Deux bd Dorsales (une base avec les données « référentiel » pour les différentes listes déroulantes par exemple, une avec les données rentrées par les agents de terrain)

La base n’est pas en réseau : sur chaque poste l’ensemble est installé.
Comme le parc informatique est très hétérogène, j’ai décidé d’utiliser le runtime.

Pour créer le runtime (Access 2003) :
J’ai transformé la base frontale en .mde et je l’ai empaquetée en ajoutant mes deux bases dorsales en .mdb (dans l’étape 4 de l’empaquetage)

Test du runtime sur un poste avec Access 2000 :
Pour l'installer sur un poste, je lance donc le Setup.exe pour installer la base de données frontale. Tout fonctionne à peu près bien …
Mais en fait, j’ai l’impression que les bases dorsales ne sont pas jointes dans le paquetage. Il fait toujours le lien avec les deux tables .mdb d’origine …

Est-ce normal ou cela est-il susceptible de me poser des problèmes si on installe ce runtime sur un poste sans aucune version de microsoft access par exemple….?
Est-ce qu’on doit empaqueter les deux bases dorsales à part ?

Je pense que je ne comprends pas tout dans la logique du runtime …. si quelqu’un y voit plus clair, je suis intéressée par toutes suggestions !

[marot_r]

Les bases dorsales, normalement, ne sont pas distribuées avec l'application puisqu'elles sont communes à tous les utilisateurs.

Elles sont généralement installées à demeures sur un serveur visible de tous les utilisateurs (ex : z:\MonAppli\MesDonnees\MaBase.mdb).

A+

[Julie!!!]

Ok ! ... Merci marot_r

En fait l'organisme où je suis ne veut pas mettre le projet sur le serveur...
La BD est quand même scindée pour faciliter les mises à jour et au cas où ils changeraient de politique là dessus.

Du coup, je n'ai pas du tout à joindre mes bases dorsales dans l'empaquetage.... Je vais juste les sécuriser.

Mais est-ce que quelqu'un sait si ca ne risque pas de bugger comme elles resteront en base access 2003 sur des postes non équipé de cette version d'access ??

Me conseillez vous de tout remettre en une seule base ?

[argyronet]

Bien en fait, on justifie le choix du runtime dans un souci d'économie de coût de licence d'une part et qui se justifie aussi par le fait que les utilisateurs finaux ne savent ou n'ont pas besoin d'avoir Access sur leur poste d'autre part dans la majeure partie des cas.

MS Access Runtime et MS Access sont identiques : Même moteur, même fonctionnalités sauf restrictions (Voir mon tuto) mais la version Runtime est une version bridée empêchant toute intervention sur la base.
En fait, on ne peut pas ouvrir manuellement une BDD sur une version du Runtime.

En ce qui concerne la réponse de marot_r, il appuie le fait que les données étant partagées, il est évident qu'elle sont censées déjà exister quelque part.
Imagine par exemple que ces données soient sur un serveur SQLServer ou Oracle , voir MySQL et que tu utilises Access pour les gérer, tu ne peux pas embarquer la BDD source dans ton package. Dans ces conditions, c'est à ton programme de détecter la présence de la base de données source avec un message d'erreur idoine en cas d'échec.

Dans ton package, il ne doit y avoir aucune données.
A la limite, une BDD vide dorsale mais c'est un cas extrème où par exemple, tu distibues une application à un client distant qui n'a pas de serveur et où le programme se chargearait de migrer la BDD dorsale sur un ordinateur dédié et ensuite de rattacher automatiquement les tables au MDE...

Il ne faut en aucun cas que chaque poste possède une BDD Dosale locale.
Comment vas-tu récupérer et centraliser les données ?

Envoyé par Julie

En fait l'organisme où je suis ne veut pas mettre le projet sur le serveur...

C'est pas la projet, mais une BDD qu'avec des tables.
Si tu veux la sécuriser, tu optes pour un MDW sur celle-ci.

Pour les postes déjà équipé d'Access 2003, il n'y aura aucun souci de compatibilité, sauf si la version locale est ultérieure (2007).

Argy

[Julie!!!]

Bonjour,

Merci Argyronet pour ta réponse.

Voici quelques spécificités sur le système d'information mis en place qui explique les choix faits (pas d'utilisation de serveur et base complète sur chaque poste) :
- la centralisation des données n'a pas besoin d'etre trop frequente : 1 fois par an suffit. (les données sont saisies et exploitées par les sous directions départementales de l'organisme; centralisées pour statistiques et archivage au niveau régional)
- Un département n'a pas d'utilité à consulter les infos saisies par les autres départements.
- l'administrateur du réseau a evoqué des problèmes de connexion "Internet" dans certains départements, puis a refusé catégoriquement de mettre la base sur le serveur … en me disant que ce n’est pas la politique de la maison… que seuls les projets nationaux peuvent utiliser les serveurs ...

Ainsi, annuellement, les départements envoient une copie de leurs bases dorsales à la région : via un bouton de commande "Importer", on efface tous les anciens enregistrements du département de la base régionale puis on y ajoute tous les enregistrements de la copie de la base de l'année.

Ca fait un peu bidouillage mais vu nos besoins, ça semble suffire. Sauf que dans les départements ils n'ont pas la même version ACCESS qu'à la région...
D'où l'utilisation du runtime et le problème des bases dorsales sur chaque poste.
Qu'en penses tu, Argyronet ?
Toutes les remarques sont les bienvenues !

Julie

[marot_r]

Ta solution fait du sens dans ton cas mais as-tu un seul utilisateur de ta base dans chaque département ?

A+

[Julie!!!]

Bonjour marot_r,

Oui, en effet, nous avons un correspondant par département sur la base et elle est installée sur un seul ordi dans chaque département.
Mais bon, c'est vrai que ça fait pas un système très élégant .... ....

Du coup, j'aurais aimé mettre automatiquement les bases dorsales dans le répertoire adequate sur l'ordinateur du correspondant, afin de lui limiter la manipulation de fichiers. Est-ce possible par l'empaquetage ?
J'avais cru comprendre dans un message précédent d'Argyronet que c'etait possible, mais je n'ai pas bien compris comment...

Julie

[marot_r]

Pour l'empactage je ne sais pas. Je n'utilise pas cet outil pour mes déploiements.

Par contre le disque local de ton utilisateur est-il sauvegardé régulièrement ? Si non, tu voudras surement mettre ta base dorsale sur une machine sauvegardée ou faire automatiquement une copie sur une machine sauvegardée.

A+

[argyronet]

Bien, Julie, dans un cas similaire, je profitais de l'événement qui précède la fermeture de l'application pour effectuer une copie de la base vers un dossier de backup... et ce de façon transparente pour l'utilisateur...

Pour mettre la base dorsale dans chaque package ou dans le package, il suffit que tu relances ton assistant déploiement et que tu ajoutes la dite base de données.

Tu vas jusqu'au bout et tu vérifies qu'elle est bien copiée dans AppPath$.

Ensuite, si tu as une BDD dorsale différente pour chaque département, tu peux alors générer un script d'empaquetage en utilisant un script existant. (Voir rubrique "Evolution de votre package") et le sauvegarder sous le nom du département correspondant...

Argy