Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

3 réponses
Avatar
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
---- ---- ----

3 réponses

Avatar
CErnst
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" a écrit dans le message de news:

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
---- ---- ----






Avatar
Blaise Cacramp
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" a écrit dans le message de news:
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" a écrit dans le message de news:

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
---- ---- ----










Avatar
barlou
On 27 juin, 20:25, "Blaise Cacramp" wrote:
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