Évolution d’une application existante. Quel choix ?

[BBerni]

Bonjour à tous,

Je vous soumets un sujet qui a déjà été débattu à mainte reprise, mais je souhaite définir la problématique avec laquelle je vis et en débattre. Le but est de collecter un max d’info pour soumettre un plant à mon président.

Nous sommes une PPE (petite petite entreprise) et quelqu’un à développé une application ACCESS (VBA et BD Access). Or avec le temps, l’application a grossi ET SURTOUT elle devient de plus en plus LENTE.

Le nombre d’utilisateurs est < 15 et le but est de gérer toutes nos activités relatives à la fabrication unitaire de machine (une machine par mois et en mode projet) . La bd (BackEnd en langage ACCESS) est sur le serveur et il y a une copie de l’application par PC.

Voici mes questions :
1) Quels est la possibilité de faire pour augmenter la vitesse ? Comment ? Pourquoi ?

2) Est-il judicieux de convertir le code VBA en Delphi par exemple ? (Il va falloir revoir l’ergonomie de nombreux écrans, donc . . . ) Comment ? Pourquoi ?

3) Si je passe par un changement de technologie, laquelle sélectionner ? Pourquoi ? Il y a un préjugé favorable pour Delphi, mais je suis ouvert à étudier d’autre(s) solution(s)

4) Tous autres points qu’il est important de discuter . . .

5) Quels sont les coûts associés à ces technologies ?

D’avance, je remercie tous les participants.
Bonne journée.

B

[qi130]

1) Quels est la possibilité de faire pour augmenter la vitesse ? Comment ? Pourquoi ?

En vrac pour ce point:
1/ augmenter le débit du réseau si c'est possible (si vous êtes en ethernet 10Mb, passez au 100 Mb -> changer les cartes et autres matériels)
2/ augmenter la capacité du serveur (processeur, mémoire, HD+rapide)
3/ purger la BD
4/ optimiser le code

Maintenant, le pourquoi de tout ça ne peut venir qu'après connaissance + fine des éléments mis en cause ci-dessus (topologie réseau, architecture de l'appli, etc...)

2) Est-il judicieux de convertir le code VBA en Delphi par exemple ? (Il va falloir revoir l’ergonomie de nombreux écrans, donc . . . ) Comment ? Pourquoi ?

Ca ne peut être qu'un choix d'entreprise.... ou pour se faire plaisir 8)
Cela dépend de l'appli actuelle. Par exemple si elle fait beaucoup de calculs, ça peut valoir le coup (cf l'accueil Delphi et le test "contre" VB).
Une solution de repli consisterait à changer "simplement" le SGBD.

3) Si je passe par un changement de technologie, laquelle sélectionner ? Pourquoi ? Il y a un préjugé favorable pour Delphi, mais je suis ouvert à étudier d’autre(s) solution(s)

Vaste sujet!
Tout dépend des compétences qui seront mises en oeuvre (internes vs. s/traitance) => et aussi du taux de maintenance de l'appli, du besoin de réactivité en cas de pb ou d'évolution, de la capacité d'apprentissage des compétences internes si elles sont retenues (résistance au changement, fracture technologique, etc...). bref autant de choses qui ne coulent pas forcément de source dans une PPE
Quant au langage, pourquoi pas Delphi. Je lui trouve le mérite de structurer suffisament les développements tout en bénéficiant d'un excellent niveau de support.

Pour le point 4: demande une rallonge

Et pour le 5, visite obligatoire sur les sites des fournisseurs !

Voilà, j'espère avoir éclairé un peu ta lanterne.

[Marmot]

Nous sommes une PPE (petite petite entreprise) et quelqu’un à développé une application ACCESS (VBA et BD Access). Or avec le temps, l’application a grossi ET SURTOUT elle devient de plus en plus LENTE.

Access n'est pas fait pour travailler en client-serveur me semble-t-il, du coup si ta base fais 100Mb chaque utilisateur importe chez lui 100Mb sur le réseau à chaque accès (consultation/modification) à la base.

Augmenter le débit réseau est une solution mais à court-moyen terme c'est rebelotte.
Augmenter la capacité du serveur Access n'y étant pas exécuté je vois mal ce que ça va changer.
Purger la BD permet de diminuer la taille de la BD, toujours uns solution à court-moyen terme.
Optimiser le code, mouais, avec les PC actuels tu auras plus un gain en seconde qu'en minute..

Moi je t'encouragerai plutôt vers un redéveloppement en client-serveur ou un portage de l'appli Access sur Intranet.

[qi130]

Augmenter la capacité du serveur Access n'y étant pas exécuté je vois mal ce que ça va changer.

Simplement qu'en fonction des caractéristiques du serveur actuel qui dépendent de son ancienneté, on peut arriver à gratter 10 ou 20 % de perf en plus:
- temps d'accès du HD
- mémoire tampon du HD (buffer)
- technique de l'interface du HD (IDE // E-IDE // ATA // SCSI) permettant d'atteindre du haut débit de transfert

mais, la carte-mère ne doit pas être en reste quant à sa capacité à acheminer les données lues (largeur du bus) vers le processeur (nb de cycle d'horloge pour traiter 1 mot) puis vers la RAM pour stockage avant la confection des paquets Ethernet à expédier vers le demandeur.

Bien sûr que ça ne rajeunit pas 1 appli qui vieillit mal, juste ça aide, et ça répond en partie à la question n°1...

[Admin]

Envoyé par Marmot

Access n'est pas fait pour travailler en client-serveur me semble-t-il, du coup si ta base fais 100Mb chaque utilisateur importe chez lui 100Mb sur le réseau à chaque accès (consultation/modification) à la base.

Ca c'est une idée recu, tu ne transfert pas toute la base à chaque Accès !
Et heuresement !

Access possède des lacunes sur la partie transactionelle, mais tu peux très bien faire du "client-serveur" quoi que le terme soit galvaudé, c'est un SGBD fichier.

Maintenant concernant les axes d'évolutions, effectivement agir du coté machine via l'accès aux disques durs, le réseau c'est une solution simple quoi que à mon avis peu efficace et qui trouvera vite sa limite.

Pensez coté nouveau developpement, là par contre tu dois pouvoir faire des trucs sans te ruiner.

Passer à VB6 avec une base MySQL par exemple.
Pourquoi ce choix :
MySQL est gratuit et supportera largement la volumétrie que tu enonces.
Les couts de migration de Access à VB6 seront minimes etant donné la similitude qu'il peut y avoir entre les deux langages, il y aura surement pas mal de chose à revoir mais dans l'ensemble les codes seront similaires.

Delphi est effectivement un bon choix, car c'est un produit puissant et assez optimisé pour la gestion de base de données, attention tout de même Delphi 8 necessite de connaitre .NET
Pour ton cas, je pense que Delphi est peut-etre de la grosse artillerie.

Coté Base de données, si tu veux passer à des bases qui inclus la gestion des transactions ou les requetes imbriquées, la solution logique pour VB est SQLServer.

[Marmot]

Ca c'est une idée recu, tu ne transfert pas toute la base à chaque Accès ! Et heureusement !

Ah, ok, pour éviter que je ne propage d'autres idées reçues sur Access (97-2000) tu pourrais me renseigner une doc (même en anglais) qui fait le point sur ce qui transite sur le réseau qunad j'interroge une BD Access ?

Merci

[Admin]

Là franchement tu me poses une colle !

[BBerni]

Bon, je suis de retour . . . et merci pour les réponses.

Optimiser le matériel (réseau, serveur, etc), oui, mais je pense que la limite sera vite atteinte, car j’ai fais un test avec tout sur ma machine, et je ne vois pas de miracle (Je suis à Montréal pas à Lourde. Eh . . . )

MySQL : je viens de lire dans « Control Engineering » avril 2004, que la compagnie propriétaire viens de modifier les licences d’utilisations et qu’il y a bien des utilisateurs qui se sont fait piéger!!!

Je me méfie des choses qui sont gratuites. VB aussi est « gratuit » mais tu payes à l’utilisation (c’est lent est les utilisateurs sont payés pour attendre, les modifications plus ou moins compliquées, etc.) En plus de te retrouver dans la « prison » MS.

Delphi : je pense à Delphi, car nous avons Delphi 6 et que j’en ai une relative bonne connaissance, en plus d’avoir codé pendant plus de dix ans en C++ dans le domaine de l’automatisation. Et aussi du système expert G2 (gensym.com) Dans ma stratégie de conversion, je pense faire la migration module par module.

Après la lecture de vos réponses, je peux dire que la base est composée de ~50 tables (pas toujours normalisées) et utilise beaucoup de requêtes. Le tout est composé de 3 modules : le module avec les tables (50M), et ensuite les 2 modules App1 (11M) et App2 (14M).

Bonne journée.

[ovh]

Tu as tort de te méfier de tout ce qui est gratuit : la plupart des technologies open source sont gratuites et sont fiables et très utilisées. Mais c'est un autre débat.

Sinon en terme de BD pourquoi pas MSDE ? C'est la version light (et gratuite ) de SQL Server, donc Access devrait pouvoir travailler avec très facilement.

D'autre part, tu peux toujours utiliser Access comme interface qui s'appuie sur une autre BD client/serveur, comme par exemple MySQL ou PostgreSQL via leur driver ODBC.

Quand Access travaille avec une BD client/serveur il n'y a aucun problème de charge réseau puisqu'on travaille en mode c/s.

Cependant Delphi est un très bon choix aussi.

[fadace]

Envoyé par ovh

Sinon en terme de BD pourquoi pas MSDE ? C'est la version light (et gratuite ) de SQL Server, donc Access devrait pouvoir travailler avec très facilement.

Ben simplement parque que MSDE est fait pour 5 utilisateurs concurrents et pas 15

Par contre, l'idee de ne passer dans un premier temps que la partie serveur sur un SGBDR meilleur que le JetEngine de Access est bonne et a moindre cout (mais il faudra quand meme repasser a travers l'appli pour gomer les specificites Access et rendre le code plus performant, par ex en utilisant des procedures stockees).