Discussion :

[Beralienne]

Bonjour,

Je viens de découvrir et lire attentivement le tutoriel de Jean-Pilippe Ambrosino sur le déploiement et empaquetage des application professionnelles Access 2007, et les différentes discussions du forum. Ce fut super intéressant !!!! Mais je reste sur ma fin concernant 2 points que je n'arrive pas à éclaircir.

Je m'explique, je vais concevoir un logiciel de traçabilité (peut-être et fort possible avec access et donc runtime). Mon but est de pouvoir mettre la base de données sur le serveur de la boite dans laquelle je bosse, et mettre une application (qui permettrait de consulter et compléter la base de données) sur plein d'autres de postes de la boite.

Serait-il possible dans une application ouverte avec le runtime, de compléter la BD, modifier certaines données de la BD? (c'est l'un des points qui m'est un peu flou)

Le second point (et dernier) serait de savoir comment ça se passerait si plusieurs opérateurs utilise l'application (qui serait installée sur chaque poste je le conçois bien) mais en même temps, si par exemple plusieurs opérations de sauvegarde de données viendraient à se faire en même temps sur l'unique BD se trouvant sur le serveur?
est-ce que c'est possible d'abord avec access? permet-il de gérer ce problème?

Merci beaucoup de vos réponses.

[marot_r]

Bonjour,
Serait-il possible dans une application ouverte avec le runtime, de compléter la BD, modifier certaines données de la BD? (c'est l'un des points qui m'est un peu flou)

Le RunTime est un access restreint, il te permet de faire la plus part des choses que fait access mais pas de modifier une application (par ex : modifier la structure d'un formulaire, ajouter ou retrancher du code ou des macros). Il te permets donc sans problème d'accéder à tes données et de les modifier.

Quand tu déplois une application RunTime il faut mettre des formulaires pour tout se que tu permets à ton utilisateur. Par exemple pour compléter ta table produit, il te faut un formulaire de saisie basé sur cette table.

Le second point (et dernier) serait de savoir comment ça se passerait si plusieurs opérateurs utilise l'application (qui serait installée sur chaque poste je le conçois bien) mais en même temps, si par exemple plusieurs opérations de sauvegarde de données viendraient à se faire en même temps sur l'unique BD se trouvant sur le serveur?

Un des intérêts principal de la distribution de l'application sur les postes et de la BD sur le serveur est d'avoir des meilleurs temps de réponse. Chaque utilisateur roule son appli mais dans la base sur le serveur Access gère les accès. Il sait donc qui utilise quoi et il gère les conflits.

est-ce que c'est possible d'abord avec access? permet-il de gérer ce problème?

oui.

[Beralienne]

(pas de connexion web du week end dsl de répondre si tard !! )

yeahhh !! merci beaucoup pour tes réponses !! tu m'enlève un énorme poids !!!!

Heu juste un souci : le serveur tourne sous linux et tous les autres postes sous windows... alors que access est typique windows.
Est-ce que il y aurait un moyen que ça marche quand même?
Parce que d'après ce que j'ai compris de ce que tu m'as dit, access serait installé sur le serveur, non?

Ou faut-il juste que le fichier BD soit sur le serveur et c'est runtime qui gère le reste de chaque poste, (avec access d'installé sur un poste windows le temps de réaliser l'application)?

[marot_r]

Heu juste un souci : le serveur tourne sous linux et tous les autres postes sous windows... alors que access est typique windows.
Est-ce que il y aurait un moyen que ça marche quand même?
Parce que d'après ce que j'ai compris de ce que tu m'as dit, access serait installé sur le serveur, non?

Non, seulement la base dite dorsale (c-à-d celle qui contient tes données.) C'est vu comme un simple fichier texte normalement. Donc si tu peux par exemple stocker des fichiers Excell et tout de même les exécuter à même tn serveur, ça devrait marcher.

Ou faut-il juste que le fichier BD soit sur le serveur et c'est runtime qui gère le reste de chaque poste, (avec access d'installé sur un poste windows le temps de réaliser l'application)?

Tu as besoin d'au moins un poste de développement avec un 'vrai' Access et sur chaque poste client tu peux n'installer que le runtime.

A+

[Beralienne]

Bonjour, ça m'éclaircit la tête !!

Tu m'as bien aidé sur ce sujet!! j'étais toute contente d'avoir enfin trouvé la solution à mon logiciel.
"étais" car j'ai découvert que des postes de l'atelier tournent encore sous windows 95, 98 et millénium!!!!! donc c'est mort pour le runtime il est pas compatible et il faut absolument que l'application soit sur ces postes.
Donc à parement les boss serait plus tenté par excel avec vba, et ils ne voudront jamais mettre a jour les vieux pc -_- !!!!!
donc voilà
Mais merci beaucoup pour tes explications.

[marot_r]

Bonjour, ça m'éclaircit la tête !!

Tu m'as bien aidé sur ce sujet!! j'étais toute contente d'avoir enfin trouvé la solution à mon logiciel.
"étais" car j'ai découvert que des postes de l'atelier tournent encore sous windows 95, 98 et millénium!!!!! donc c'est mort pour le runtime il est pas compatible et il faut absolument que l'application soit sur ces postes.
Donc à parement les boss serait plus tenté par excel avec vba, et ils ne voudront jamais mettre a jour les vieux pc -_- !!!!!
donc voilà
Mais merci beaucoup pour tes explications.

Si tu veux te battres là dessus tu pourrais monter un tableau Excell qui mets en relation les coûts de l'usine à gaz que tu vas devoir faire avec Excell et les couts et avantages de la mise à niveau de tes systèmes de prod.

Mais j'ai eu un patron comme cela, on ne dépensait pas 3 sous pour des boites à archive mais on me payait 100000 F/an pour bricoler à partir de carton de récup ces boites dont j'avais besoin.

A+