Discussion :

[snoopy69]

Bonjours à tous ...

Je suis en train d'effectuer la rédaction d'un "bilan" sur un projet que j'ai entrepris il y a maintenant 6 mois ...

Voici ma situation :

J'ai créer une base de données (Access 2003) comportant environs 25 tables, 40 formulaires, 10 états, et 30 requêtes ... ( on ne parle pas des modules ... )

Ma base de données est séparées c'est à dire :

6 fichiers sur un serveur. Ces 6 fichiers contiennent les tables.
1 fichier en local sur chaque poste contenant les formulaires, les requêtes .. etc ...

Il y a environ par jour 15 à 20 personnes qui sont connectées sur la base de données ... ( évidemment cela ralenti un peu le fonctionnement ) ...

Dans 4 de mes tables il y a environs 80'000 enregistrements ... cela dépend de la production en fait ...

Ma question est la suivante :

Que pensez-vous de cette situation, devrais-je migrer ma base de donnée sur un autre système de gestion comme Sql Serveur et garder comme interface Access ???

Que me conseillez-vous ??? Et si je dois changer mon système de gestion, cela sera dans quel but ???

Merci de votre aide ... et à bientôt

[marot_r]

Salut,

Tes utilisateurs se plaignent-ils ?

As-tu des problèmes de fiabilité ?

Quelle est la perspective de croissance de ton applis (enrs, utilisateurs) ?

C'est la réponse à ce genre de questions qui va te donner la valeur ajouter de ta migration, sinon touche à rien :-)

A+

[mat.M]

Dans 4 de mes tables il y a environs 80'000 enregistrements ... cela dépend de la production en fait ...

Ma question est la suivante :

Que pensez-vous de cette situation, devrais-je migrer ma base de donnée sur un autre système de gestion comme Sql Serveur et garder comme interface Access ???

Comme le dit mon prédecesseur si ça tourne bien pq changer ?
Tout dépend si tu as des requêtes croisées complexes qui demandent du temps
Tu peux toujours décharger l'appli en recréant des écrans de saisies sous VB6/NET , Delphi , C++ Builder..
Avec ADO on accéde facilement à une BDD ACCESS

40 formulaires cela parait un peu gros pour une BDD Access

[snoopy69]

Pour l'instant, ma base de données n'est pas encore exploitée en temps réel ... c'est à dire que nous avons effectués des tests avec seulement 10 personnes connectés dans 10 départements différents ...

Voici ce que j'ai constaté :

1) J'ai créer des formulaires qui permette de trier les données d'une table de 80'000 enregistrements ... lorsque plus de 5 personnes ouverent ce formulaires, il y a un ralentissement qui se produit ... ( 10 sercondes pour triéer des données )

2) Dans certains des mes formulaires, j'ai des impressions automatiques qui se produisent c'est à dire que tout dépend les données que l'on rentre dans le formulaire tel ou tel état s'imprime avec tel ou tel données ... ... J'ai remarqué que si 2 personnes sont sur le même formulaires en même temps et qu'il rentre les même données qu'il y a un temps très long pour que l'état s'imprime ... ... ( l'impression se lance au bout de 35 secondes ) ...

Que pensez-vous de cela ???

La migration serait-elle un aventage ???

Si oui, sur quel SGBD devrais-je migrer ???

Merci à tous pour vos différents avis ... et à tout bientôt ...

[kirgan]

Hello,

je ne connais pas suffisamment Access pour pouvoir te dire que c'est mieux de migrer ou pas.

Par contre, je connais suffisamment VB .net et SQL Server pour savoir que si tu comptes refaire avec ces outils-là une application qui compte 40 écrans, un module d'impression, une BD de 25 tables, la gestion des utilisateurs, tout cela à un coût non négligeable. Même si tu refais ca petit à petit, le coût ressources est élevé. Et je ne te parle même pas des licenses SQL Server et .net si tu ne les as pas...

Je suis un grand convaincu des "gros systèmes" tels .net et sql server (on se refait pas), mais il faut vraiment voir tes besoins, car ca risquerait d'exploser le budget informatique d'une pme.

PS: je ne connais pas ta formation ni tes connaissances en gestion de projet. Il y a des outils (ou des règles) pour se donner une idée de ce que coute le développement par écran, par module, en fonction d'entrées/sorties etc. Va jeter un coup d'oeil sur le net, ca vaut à mon avis 2-3 heures de recherche que d'avoir une vision claire du coût.

[marot_r]

Pour l'instant, ma base de données n'est pas encore exploitée en temps réel ... c'est à dire que nous avons effectués des tests avec seulement 10 personnes connectés dans 10 départements différents ...

Et ta charge réelle sera ?

Voici ce que j'ai constaté :

1) J'ai créer des formulaires qui permette de trier les données d'une table de 80'000 enregistrements ... lorsque plus de 5 personnes ouverent ce formulaires, il y a un ralentissement qui se produit ... ( 10 sercondes pour triéer des données )

Le nombre officiel d'utilisateur simultané est de 255 mais d'après mes lectures, notement l'excélent tuto sur la migration d'access vers Oracle référencé sur ce site, 5 semble être le nombre réel. Donc pas de vraiment une surprise.

2) Dans certains des mes formulaires, j'ai des impressions automatiques qui se produisent c'est à dire que tout dépend les données que l'on rentre dans le formulaire tel ou tel état s'imprime avec tel ou tel données ... ... J'ai remarqué que si 2 personnes sont sur le même formulaires en même temps et qu'il rentre les même données qu'il y a un temps très long pour que l'état s'imprime ... ... ( l'impression se lance au bout de 35 secondes ) ...

Voir réponse précédente.

La migration serait-elle un aventage ???

Oui, Oracle par exemple supporte bien mieux la charge qu'Access. Je ne connais pas SQL Server ni les autres BDD.

Si oui, sur quel SGBD devrais-je migrer ???

Ca dépend :
1) De la charge prévue
2) De ton budget
3) De tes connaissances
4) Du temps dont tu dispose

Personnelement j'ai une expérience de migration vers Oracle 9, et cela à accroché sur les point suivants :
- Nom des champs (30 char Max dans Oracle)
- Champs mémo (Max 4096 car ds Oracle)
- Clef primaire (Pb avec les noms par défaut et le drivers ODBC)
- AutoNum (Les autonum d'ORacle sont calculés APRES l'enr, ceux d'Access AVANT !)
- Drivers ODBC
- NotMatch qui ne fonctionne pas (Renvoi systématique du dernier enr si pas trouvé)
- Pb de perfo sur CERTAINS postes
- Obligation de transférer certaines requètes Access complexes vers des vues Oracle

Avantage :
- Plus de pb de charge, ni d'inter blocage, ni de corruption de la base.
- Sécurité accrue, gérée au niveau de la BDD

Configuration de mon appli :
Access XP, Oracle 9, BDD Oracle centralisée, Application sur 30 postes clients répartis sur 10 sites environs. Usage : 1/2j par pers en moyenne

Temps pour la migration : 1.5 mois

Personnel impliqué :
- 1 Prog Access Moyen & Oracle expert, temps plein
- 1 Expert Oracle, mi-temps
- 1 Expert Access (moi :-) 1/10 temps

A+

[mat.M]

Pour l'instant, ma base de données n'est pas encore exploitée en temps réel ... c'est à dire que nous avons effectués des tests avec seulement 10 personnes connectés dans 10 départements différents ...

Eh attention : tests et explotation réelle y'a souvent des grosses suprises.
La charge n'est pas la même

Même si tu refais ca petit à petit, le coût ressources est élevé. Et je ne te parle même pas des licenses SQL Server et .net si tu ne les as pas...

Licence .NET ??? Pas besoin d'avoir de licence .NET ! Tu peux très bien distribuer un programme .NET sans royalties.
Par contre pour SQL Server oui
Tu raisonnes à l'économie et aux économies de bout de chandelle.
Mais vaut mieux passer un système informatique de base vers un autre plus costaud.
Parce qu'un système sous Access cela sera autant couteux à maintenir pour des performances moindres

[kirgan]

Licence .NET ??? Pas besoin d'avoir de licence .NET ! Tu peux très bien distribuer un programme .NET sans royalties.

Si c'est en interne, il doit développer son application. VS est pas affreusement cher, mais chaque centime compte pour certaines petites boîtes... Je parlais en effet des coûts de développement.

Je reste convaincu que la différence de budget entre Access et MSSQL+VB peut être relativement importante pour une entreprise de quelques employés. Mais je ne dirai jamais que ca ne vaut pas la peine, il s'agit de 2 mondes différents. Tout est fonction des besoins.