Passage Access 2002 -> sql server (T-SQL) votre expérience de gains de performances

Le
Blaise Cacramp
Selon : Bonjour ou bonsoir

<bla bla>
On m'en fait voir de toutes les couleurs!

Mon employeur actuel a divisé mon travail en quatre modules pouvant être
indépendants en me mettant des oeillères. En bref, en commençant le module
2, j'ai dû modifier la structure de ce qui avait été fait dans le 1, et je
sais que ce sera la même chose avec les 3 et 4 (et peut être encore plus).

Et ainsi donc ce qui au départ devait être une gentille BD devient tout
doucement un monstre.
L'application est du style frontales dispersées et une dorsale qui contient
actuellement 48 tables, je ne sais combien d'index, de relations

La mise en production se fait au fur et à mesure (Bonjour le stress après
chaque modif de structure).

Bon donc je crois que j'aurais au final moins de 60 tables et probablement
moins de 20 utilisateurs simultanés.

J'ai déjà des requêtes de reporting (avec VBA) qui rament, des bêtes
formulaires qui mettent un temps certain avant d'être opérationnels.

Donc, alors que le bidule n'est pas fini, je touche déjà les limites
d'Access.
</bla bla>

Je voudrais donc avoir un petit serveur SQL (j'ai jamais fait mais je
connais), mais l'investissement ne dépend
pas de moi.
Je dois donc argumenter pour vanter les mérites du passage.

Et ma requête est donc :

*** pouvez-vous me faire part de votre expérience et des gain enregistrés
lors du passage Access (2002) -> SQL Server (2005) ***




Cdt, Blaise
- - -
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
CErnst
Le #19653271
Vous aurez plus de puissance, plus de vitesse ou en tout cas une vitesse
homogène.
Le nombre de tables et d'utilisateurs ne sera plus un problème.
voilà pour votre patron.

mais pour vous :

Si vous optez pour une base ADP :
Va falloir tout reprogrammer en ADO...... (ou si vous avez programmé Access
en ADO, faire pas mal de retouches)
vous aurez des surprises dans les formulaires, les sous-formulaires, le
fonctionnement de certaines requètes différent de celui d'Access..
Vous pourrez faire des modifications de structure en dynamique..
bref, des choses à découvrir...

si vous optez pour la liaison Odbc sur une base MDB, vous aurez bien mons de
retouches, mais il y en aura quand-même.







"Blaise Cacramp"
Selon : Bonjour ou bonsoir

<bla bla>
On m'en fait voir de toutes les couleurs!

Mon employeur actuel a divisé mon travail en quatre modules pouvant être
indépendants en me mettant des oeillères. En bref, en commençant le
module
2, j'ai dû modifier la structure de ce qui avait été fait dans le 1, et je
sais que ce sera la même chose avec les 3 et 4 (et peut être encore plus).

Et ainsi donc ce qui au départ devait être une gentille BD devient tout
doucement un monstre.
L'application est du style frontales dispersées et une dorsale qui
contient
actuellement 48 tables, je ne sais combien d'index, de relations ...

La mise en production se fait au fur et à mesure (Bonjour le stress après
chaque modif de structure).

Bon donc je crois que j'aurais au final moins de 60 tables et probablement
moins de 20 utilisateurs simultanés.

J'ai déjà des requêtes de reporting (avec VBA) qui rament, des bêtes
formulaires qui mettent un temps certain avant d'être opérationnels.

Donc, alors que le bidule n'est pas fini, je touche déjà les limites
d'Access.
</bla bla>

Je voudrais donc avoir un petit serveur SQL (j'ai jamais fait mais je
connais), mais l'investissement ne dépend
pas de moi.
Je dois donc argumenter pour vanter les mérites du passage.

Et ma requête est donc :

*** pouvez-vous me faire part de votre expérience et des gain enregistrés
lors du passage Access (2002) -> SQL Server (2005) ***




Cdt, Blaise
---- ---- ----






Blaise Cacramp
Le #19656061
Merci pour votre réponse et pour les judicieuses remarques supplémentaires.
Je suis au courant des adaptations nécessaires et, heureusement, je suis en
ADO. Mon employeur est aussi au courant qu'il faudra un certain temps de
migration
"CErnst" eLp0%
Vous aurez plus de puissance, plus de vitesse ou en tout cas une vitesse
homogène.
Le nombre de tables et d'utilisateurs ne sera plus un problème.
voilà pour votre patron.

mais pour vous :

Si vous optez pour une base ADP :
Va falloir tout reprogrammer en ADO...... (ou si vous avez programmé
Access en ADO, faire pas mal de retouches)
vous aurez des surprises dans les formulaires, les sous-formulaires, le
fonctionnement de certaines requètes différent de celui d'Access..
Vous pourrez faire des modifications de structure en dynamique..
bref, des choses à découvrir...

si vous optez pour la liaison Odbc sur une base MDB, vous aurez bien mons
de retouches, mais il y en aura quand-même.







"Blaise Cacramp"
Selon : Bonjour ou bonsoir

<bla bla>
On m'en fait voir de toutes les couleurs!

Mon employeur actuel a divisé mon travail en quatre modules pouvant être
indépendants en me mettant des oeillères. En bref, en commençant le
module
2, j'ai dû modifier la structure de ce qui avait été fait dans le 1, et
je
sais que ce sera la même chose avec les 3 et 4 (et peut être encore
plus).

Et ainsi donc ce qui au départ devait être une gentille BD devient tout
doucement un monstre.
L'application est du style frontales dispersées et une dorsale qui
contient
actuellement 48 tables, je ne sais combien d'index, de relations ...

La mise en production se fait au fur et à mesure (Bonjour le stress après
chaque modif de structure).

Bon donc je crois que j'aurais au final moins de 60 tables et
probablement
moins de 20 utilisateurs simultanés.

J'ai déjà des requêtes de reporting (avec VBA) qui rament, des bêtes
formulaires qui mettent un temps certain avant d'être opérationnels.

Donc, alors que le bidule n'est pas fini, je touche déjà les limites
d'Access.
</bla bla>

Je voudrais donc avoir un petit serveur SQL (j'ai jamais fait mais je
connais), mais l'investissement ne dépend
pas de moi.
Je dois donc argumenter pour vanter les mérites du passage.

Et ma requête est donc :

*** pouvez-vous me faire part de votre expérience et des gain enregistrés
lors du passage Access (2002) -> SQL Server (2005) ***




Cdt, Blaise
---- ---- ----










barlou
Le #19660451
On 27 juin, 20:25, "Blaise Cacramp"
Selon : Bonjour ou bonsoir

<bla bla>
On m'en fait voir de toutes les couleurs!

 Mon employeur actuel a divisé mon travail en quatre modules pouvant être
indépendants en me mettant des oeillères.  En bref, en commençant le module
2, j'ai dû modifier la structure de ce qui avait été fait dans le 1 , et je
sais que ce sera la même chose avec les 3 et 4 (et peut être encore p lus).

Et ainsi donc ce qui au départ devait être une gentille BD devient to ut
doucement un monstre.
L'application est du style frontales dispersées et une dorsale qui cont ient
actuellement 48 tables, je ne sais combien d'index, de relations ...

La mise en production se fait au fur et à mesure (Bonjour le stress apr ès
chaque modif de structure).

Bon donc je crois que j'aurais au final moins de 60 tables et probablemen t
moins de 20 utilisateurs simultanés.

J'ai déjà des requêtes de reporting (avec VBA) qui rament, des bê tes
formulaires qui mettent un temps certain avant d'être opérationnels.

Donc, alors que le bidule n'est pas fini, je touche déjà les limites
d'Access.
</bla bla>

Je voudrais donc avoir un petit serveur SQL (j'ai jamais fait mais je
connais), mais l'investissement ne dépend
pas de moi.
Je dois donc argumenter pour vanter les mérites du passage.

Et ma requête est donc :

*** pouvez-vous me faire part de votre expérience et des gain enregistr és
lors du passage Access (2002) -> SQL Server (2005) ***

Cdt, Blaise
----   ----   ----



Bonjour,

J'ai pour ma part effectué une migration d'Access 2003 vers SQL server
2005 en conservant un MDB et un lien ODBC. 30 utilsateurs en moyenne
et une base de 30 Mo.
Niveau performances, j'ai noté beaucoup plus de stabilité ; je n'ai
plus de problèmes de "Compact and Repair"; La capacité de stockage est
très puissanteet les loggs de SQL permettent de suivre qui fait quoi
si besoin. De plus, les requetes lourdes peuvent être précalculées
dans SQL server ce qui améliore aussi les performances.
Pour la migration, quelques soucis dans les noms des tables, des
champs et des propriétés qui n'étaient pas conformes avant la
migration vers SQL. Donc, correction et retouche de l'application
d'origine. Pour l'ODBC, je le cré au lancement de la base sur le poste
utilisateur s'il nexiste pas encore et je lance la base avec la
version Runtime 2003.
En gros, c'est du boulot, mais le résultat est très interressant et ç a
peut permettre une phase transitoire pour un redéveloppement en
technologie web par exemple.

à +
barlou
Publicité
Poster une réponse
Anonyme