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.
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.
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.
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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
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.
c'est quoi un outil ?
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" a écrit dans le message de news:
41ff49ea$0$14471$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.
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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
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.
c'est quoi un outil ?
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" <loutox@pasici.fr> a écrit dans le message de news:
41ff49ea$0$14471$636a15ce@news.free.fr...
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.
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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
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.
c'est quoi un outil ?
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" a écrit dans le message de news:
41ff49ea$0$14471$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.
Bonjour et bienvenue sur microsoft.public.fr.access.Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.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.
c'est quoi un outil ?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" a écrit dans le message de news:
41ff49ea$0$14471$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.
Bonjour et bienvenue sur microsoft.public.fr.access.
Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?
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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.
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.
c'est quoi un outil ?
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" <loutox@pasici.fr> a écrit dans le message de news:
41ff49ea$0$14471$636a15ce@news.free.fr...
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.
Bonjour et bienvenue sur microsoft.public.fr.access.Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.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.
c'est quoi un outil ?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" a écrit dans le message de news:
41ff49ea$0$14471$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.
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))
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))
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))
Bonjour,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))
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 ?
Bonjour,
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))
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 ?
Bonjour,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))
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 ?
Bonjour et bienvenue sur microsoft.public.fr.access.Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.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.
c'est quoi un outil ?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" a écrit dans le message de news:
41ff49ea$0$14471$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.
Bonjour et bienvenue sur microsoft.public.fr.access.
Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?
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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.
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.
c'est quoi un outil ?
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" <loutox@pasici.fr> a écrit dans le message de news:
41ff49ea$0$14471$636a15ce@news.free.fr...
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.
Bonjour et bienvenue sur microsoft.public.fr.access.Je pense que ce n'est pas une bonne solution (elle a le derrière entre 2
chaises).
Pourquoi ? access n'est il donc pas un bon client pour sql server ?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.
Ceci m'etonne, 100 utilisateurs simultanés sur access. de quel type
d'application s'agit il, quel est le volume de données traitées.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.
c'est quoi un outil ?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" a écrit dans le message de news:
41ff49ea$0$14471$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.
c'est gentil d'essayer d'aider, mais mieux vaut savoir de quoi l'on parle.
c'est gentil d'essayer d'aider, mais mieux vaut savoir de quoi l'on parle.
c'est gentil d'essayer d'aider, mais mieux vaut savoir de quoi l'on parle.
