Montée en charge - Utilisateurs maximum

[consultant_banque]

Selon les specs, Access supporterai 250 utilisateurs, mais souvent, d'expérience, les développeurs parlent de beaucoup moins.
A votre avis, ces deux projets sont-ils viables ?

Deux applications Access placées sur un serveur, chaque utilisateur lance l'application située sur ce serveur.

Appli "Rapprochements" :
- Jusque 20 utilisateurs maximum en simultané. Ils travaillent tous principalement sur la même table mais avec des enregistrements différents (Requête leur attribuant les enregistrements).
- Nombre d'enregistrements : 3000 à 6000.
- Leur portion d'enregistrement sera soumise régulièrement à des filtrages ou requêtes selon critères de choix (utilisation du form.recordsource et de "form.requery").
- Opérations d'écriture : coches et indicateurs de lettrage.
- Autres opérations occasionnelles : Editions d'états / requêtes de consultation.

Appli "Indicateurs" :
- Jusque 40 utilisateurs maximum en simultané. Ils travaillent sur la même table avec des enregistrements différents.
- Nombre d'enregistrements : de 12000 à 20000
- Opération d'écriture : Entrer une date ou un commentaire.
- Filtrage : uniquement celui intégré au menu contextuel d'Access.

[vodiem]

Envoyé par consultant_banque

les développeurs parlent de beaucoup moins.

mouais on parle de 10...

je te conseil de t'orienter sur un vrai Client/Serveur.

[electrosat03]

Bonjour
Merci

Salut,
Déjà, l'application ne doit pas être sur le serveur mais sur chacun des postes des utilisateurs.

Les tables sont sur le serveur.
Le nombre d'utilisateur n'est pas exagéré, cela ne devrait poser aucun problème.

A+

[consultant_banque]

Envoyé par electrosat03

Bonjour
Merci

Salut,
Déjà, l'application ne doit pas être sur le serveur mais sur chacun des postes des utilisateurs.

Les tables sont sur le serveur.
Le nombre d'utilisateur n'est pas exagéré, cela ne devrait poser aucun problème.

A+

J'ai pensé à la solution :

Mettre les tables en "tables liées" sur une base principale, puis chaque utilisateur à sa version de l'application.

Je ne peux faire du vrai Client-Serveur car l'application Access existe déjà et mon travail est de l'adapter à un environnement multi-poste tout en implémentant de nouvelles fonctionnalités.

En cas extrême (que je souhaite vraiment éviter), je pourrais m'orienter vers une solution Base SQL-serveur avec application Access.
Cela demanderait de LIER les tables SQL-server à l'application grâce à ODBC (je n'ai jamais essayer mais je suppose que cela est possible).
Ceci occasionne des soucis car il faut créer cette base et reproduire les tables, et je ne peux le faire pour raisons de sécurité (l'informaticien interne à la banque devra le faire).
De plus, l'application ne serait plus si facilement portable dans n'importe quels environnements (réseaux d'agences). Le traitement de flux comptables est idéal sous Access (données importées, traitées, puis exportées, mais non stockées à long terme).

UNE INFO à propos de l'environnement :
Il s'agit d'un énorme Serveur ou réseau de serveurs (je n'ai pas l'info précise encore) qui sont transparents pour les utilisateurs.
Les Utilisateurs n'ont AUCUN poste ou PC à eux, ils ont juste des terminaux leur permettant de se connecter à leur espace de travail situé sur ce réseau/serveur.
Certaines applications sont propres à leur espace de travail, tandis que d'autres sont installées dans un espace commun (et les utilisateurs n'ont pas la possibilité de les installer sur leur poste virtuel).

[vodiem]

salut electrosat03 et consultant_banque,

ce que je t'en dis c'est plus un pré sentiment qu'autre chose: je n'ai pas utilisé access dans ce genre d'environnement alors qu'electrosat03 à plus d'expérience en ce domaine si je ne me trompe.

j'émets des réserves pour plusieurs raisons:
. j'ai vu couramment des recommandations en ce sens
. l'expérience me montre que déjà avec moins de 10 postes les pbs sous access peuvent engendrer de sérieux pb dans la base (cela peut provenir de faille dans la conception mais que l'on peut parfois résoudre (on peut pas empêcher l'utilisateur de couper le jus ) sinon de pb purement matériel ou il n'y a là pas grand chose à faire).
. 60 ou 40 postes (si ceux sont les mêmes) à se partager 12000 à 20000 enregistrements que j'estime à 5Mo (là je peux me tromper) de données à transférer pour chaque poste, aux heures de pointes il va falloir que le matériel suivent (sachant que le réseau n'est pas utilisé que pour cela).

si je ne doute pas que cela fonctionne je crains un délai excessif et des risques de pb sérieux lors de plantage.

mais peut être qu' electrosat03 s'aura te donner de bonnes recommandations pour tout cela.

[cbleas]

Bonjour,
Je serai plutot de l'avis de vodiem.
en effet ACCESS est un fichier et le traitement des données se font sur le poste du client. donc lorsuqe l'on veut traiter une donnée particulière dans la table l'ensemble de la table est transféré sur le poste client. au bout de quelques mois je pense que la table principale sera plutot chargée. aux heures de pointes tu auras cette table qui sera sur le réseau * le nombre d'utilisateur, solution parfaite pour faire ramer un réseau.
par contre avec ACCESS en client server (Projet adp) il n'y a que les données necessaires qui transiterons sur le réseau. de plus en cas de montée en charge il sera possible d'adapter l'environnement SQL server en fonction du besoin.
Pour ma part cela fait un certaint temps que j'ai fait la migration.

Salut,
Déjà, l'application ne doit pas être sur le serveur mais sur chacun des postes des utilisateurs.

Les tables sont sur le serveur.
Le nombre d'utilisateur n'est pas exagéré, cela ne devrait poser aucun problème.

le système doit etre mis en place sur un serveur d'application type cytrix ce qui évite de déployer sur l'ensemble des postes et ce qui permet de gagner en performance au niveau réseau.



Bonne journée