Runtime sur Serveur [Résolu]

[Philippe JOCHMANS]

Bonjour à tous,

Voilà ma question :

1 - Développement sous Access 2000
2 - Runtime 2003 sur serveur et non sur poste

Question : Si on lance le fichier mdb (partie applicative) qui est sur le serveur, il lance le runtime du serveur (on est donc pas en local). Si on ouvre à nouveau le fichier d'un autre poste que peut-t-il se passer.

Je ne peux tester pour l'instant, je pose la question avant de développer

Merci

Starec

[Tofalu]

Dans tous les cas : aucun logiciel n'est lancé sur le serveur. Access n'est pas un client / serveur de données. C'est juste un partage de fichier. Ton poste prend le fichier sur le serveur et l'exécute avec ton propre runtime.

Installer un runtime sur un serveur ne sert strictement à rien si ce n'est l'encombrer d'applications inutiles. Un serveur est un serveur, on y installe des applications serveurs. Jamais une suite bureautique puisque ce n'est pas une station de travail en théorie.

[Philippe JOCHMANS]

Re

Merci, mais où que je suis il y'a des postes fixes et Neoware qui font l'interface avec le serveur et ils utilisent les applications bureautique WORD, EXCEL du serveur.

Starec

[Tofalu]

Dans ce cas fallait être plus précis dès le début

Tu es dans une utilisation de type "terminal" alors.

Fait une recherche sur le forum, je me rappelle que JBO avait donné une réponse.

Un des mot clé possible : TSE

[=JBO=]

Bonsoir,

Envoyé par Starec

Question : Si on lance le fichier mdb (partie applicative) qui est sur le serveur, il lance le runtime du serveur (on est donc pas en local). Si on ouvre à nouveau le fichier d'un autre poste que peut-t-il se passer.

Je ne peux tester pour l'instant, je pose la question avant de développer

Sur le serveur il ya autant de sessions que d'utilisateurs connectés.
Chaque utilisateur exécute son instance du runtime.

Ensuite le fichier MDB...
Si le fichier MDB contient à la fois l'application ET les les données, alors tout tes utilisateurs travailleront directement sur le même fichier.

Access va devoir contrôler des accès concurrents sur:
1. les données
2. les objets applicatifs

La gestion des verrous sera vite très lourde avec l'accroissement du nombre d'utilisateurs.
De plus il risque d'y avoir des conflits sur certains objets applicatifs quand plus d'un utilisateur les utilise à un instant T et que l'un d'entre eux modifie leur apparence, leur organisation, leurs filtres, l'ordre de tri... et par inadvertance enrergistre la modification (si si, ça arrive... ).

-=-=-=-=-=--=-=-

Une bonne pratique consiste à:

(1) séparer les données et les objets applicatifs dans 2 fichiers MDB distincts (on parle de back-end/front-end ou dorsal/frontal pour désigner cette scission en fichiers données/application)

(2) quand un utilisateur veut exécuter son application Access, un petit programme de démarrage (batch ou scritp...) fait au préalable une copie du fichier MDB applicatif dans un répertoire "dédié" à l'utilisateur, et c'est cette copie "personnelle" qui est réellement utilisée.


Avantage du point (1):
* séparation données/application, FONDAMENTALE en environnement multi-utilisateur/multi-session, ne serait-ce que pour modifier/remplacer l'application sans toucher aux données.

Avantages du point (2):
* le fichier MDB applicatif "d'origine" est toujours intact, inchangé (en particulier, il ne subira pas le syndrôme des MDB qui grossissent à cause des requêtes).
* l'utilisateur utilise donc toujours une copie "parfaite".
* pas de conflit sur le fichier applicatif (pas de ralentissement, moins de risque d'erreurs provoquées par un conflit).
* il est possible de mettre à jour l'application sans "jeter" les utilisateurs en cours (très bien ça ) ce qui serait impossible avec un MDB unique (tout comme avec un .exe qui est forcément unique ).

Inconvénients de cette technique:
* elle ne convient pas bien pour une application qui doit fréquemment "re-connecter" des tables liées. Mais bon... qui fait faire ça à ses utilisateurs dans un environnement multi-session ? C'est plutôt un Pb d'administrateur.
* il faut gérer ces multiples copies du fichier MDB applicatif.

Voilà, c'est une recette qui a fait ses preuves.

[Philippe JOCHMANS]

Re

Merci beaucoup JBO pour ces explications.

Je suis d'accord sur le point 1, je sépare toujours mes données et mon applicatif

Je pense avoir eut les réponses à mes soucis.

Starec