Migration progressive vers sql server
Le
loutox
Salut à tous,
Prevoyant de migrer une appli access vers sql server (essentiellement pour
des raisons de performance en utilisation réseau), je suis confronté au
problème que cette appli est utilisée quotidiennement et doit donc rester
disponible.
J'étudie donc la possibilité d'un passage "progressif " dont voici l'idée
1/ dans un premier temps
=>simplement stocker les données dans une base sql server (au lieu de
l'actuelle base access arrière plan)
=> conserver ma base avant-plan inchangée (juste lier les tables vers sql
server)
à ce stade cela ne devrait apporter aucune accélération (j'espere tt de
meme que cela ne ralentira pas)
2/ Dans un deuxième temps, remplacer peu à peu les requetes et les actions
sql des formulaires et etats par leur équivalent en programmation sql
server (procédures stockées et autres ) - idem pour le code vba. l'idée est
de garder le client en access et d'appeller le T-SQL depuis VBA.
cette deuxieme étape sera effectuée par étapes. Chacune des étapes sera
testée et validée avant de passer à la suivante (RAD). Ceci permettra de
revenir rapidement en arrière pour correction en cas de problème .
Mais la question à se poser en amont est : Access est il un client
performant et satisfaisant pour bosser sur une base sql server ?
Et aussi : la methode de migration en 2 temps envisagée a elle été déja
pratiquée par quelqu'un ?
si oui quels problèmes ont été rencontrés ?
si non quelle autre méthode de migration a été utilisée ?
si vous avez un minute pour répondre, vos avis et retours d'expérience sont
les bienvenus. merci.
Contexte :
Base arriere plan sur un serveur SBS (win 2003 server)
Base avant plan sur clients Win xp pro / access 2000
15 utilisateurs
passage en douceur obligatoire : On ne désire pas tout faire d'un coup mais
y aller progressivement.
Ayant parfois expérimenté sql server et oracle, ceci sera mon premier
travail concret sur sql server.
bonne journée
Loutox.
Prevoyant de migrer une appli access vers sql server (essentiellement pour
des raisons de performance en utilisation réseau), je suis confronté au
problème que cette appli est utilisée quotidiennement et doit donc rester
disponible.
J'étudie donc la possibilité d'un passage "progressif " dont voici l'idée
1/ dans un premier temps
=>simplement stocker les données dans une base sql server (au lieu de
l'actuelle base access arrière plan)
=> conserver ma base avant-plan inchangée (juste lier les tables vers sql
server)
à ce stade cela ne devrait apporter aucune accélération (j'espere tt de
meme que cela ne ralentira pas)
2/ Dans un deuxième temps, remplacer peu à peu les requetes et les actions
sql des formulaires et etats par leur équivalent en programmation sql
server (procédures stockées et autres ) - idem pour le code vba. l'idée est
de garder le client en access et d'appeller le T-SQL depuis VBA.
cette deuxieme étape sera effectuée par étapes. Chacune des étapes sera
testée et validée avant de passer à la suivante (RAD). Ceci permettra de
revenir rapidement en arrière pour correction en cas de problème .
Mais la question à se poser en amont est : Access est il un client
performant et satisfaisant pour bosser sur une base sql server ?
Et aussi : la methode de migration en 2 temps envisagée a elle été déja
pratiquée par quelqu'un ?
si oui quels problèmes ont été rencontrés ?
si non quelle autre méthode de migration a été utilisée ?
si vous avez un minute pour répondre, vos avis et retours d'expérience sont
les bienvenus. merci.
Contexte :
Base arriere plan sur un serveur SBS (win 2003 server)
Base avant plan sur clients Win xp pro / access 2000
15 utilisateurs
passage en douceur obligatoire : On ne désire pas tout faire d'un coup mais
y aller progressivement.
Ayant parfois expérimenté sql server et oracle, ceci sera mon premier
travail concret sur sql server.
bonne journée
Loutox.
Poser une question
Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pour quinze utilisateurs, votre application access devrait être largement
performante
(j'ai couramment installé des applis sur 50 ou 100 postes) si elle est bien
faite.
S'il y a une mauvaise performance, il faudrait peut être la faire analyser
par un pro.
Ce n'est pas en changeant d'outil qu'on change l'application.
Il faudrait aller au fond de ce que propose access. Il y a largement de quoi
faire.
--
Lucky_Team
http://www.access-developpement.com
"loutox" 41ff49ea$0$14471$
Pourquoi ? access n'est il donc pas un bon client pour sql server ?
d'application s'agit il, quel est le volume de données traitées.
oui, 50 à 100 connexions avec access, moi aussi je demande à voir. sauf si chaque utilisateur utilise son micro à tour de role :o)
J'ai fait un truc comme çà de mutation sur sqlserver, j'avais d'abord j'ai la manip avec un double de la base, puis la mise en place
un samedi (mais je travaillais en profession libérale :o))
--
Pierre CFI
MVP Microsoft Access
Mail : http://cerbermail.com/?z0SN8cN53B
Site pour bien commencer
Access http://users.skynet.be/mpfa/
Excel http://www.excelabo.net
Site perso
http://access.cfi.free.fr
"loutox"
eh oui, recemment j'ai installé un serveur une nuit en semaine. chez le
client de 18H à 15H le lendemain, ça fatigue. haureusement tout s'est bien
passé.
Plus sérieusement, la partir "client " est elle restée sous access ?
--
Pierre CFI
MVP Microsoft Access
Mail : http://cerbermail.com/?z0SN8cN53B
Site pour bien commencer
Access http://users.skynet.be/mpfa/
Excel http://www.excelabo.net
Site perso
http://access.cfi.free.fr
"loutox"