j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je
pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure
méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps de
migration non négligeable dû à une réécriture importante du code (passage de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure
solution pour optmiser mon application, notamment en terme de temps de
réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql.
Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les
performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
VUILLERMET Jacques
Mon avis subjectif : les 2 solutions ne sont pas exclusives l'une de l'autre.
La solution 2 est suffisament light pour pouvoir être testé rapidement, et pouvoir comparer les performances avec l'existant.
Si cela est Ok, alors la solution 2 peut être mise en production rapidement, et la solution 1 (bien meilleure bien sûr) pourra être mise en oeuvre ensuite (plus calmement).
Jacques.
"Nono" a écrit dans le message de news: 3f950742$0$238$
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure solution pour optmiser mon application, notamment en terme de temps de réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql. Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Merci de vos réponses
Arnaud
Mon avis subjectif : les 2 solutions ne sont pas exclusives l'une de
l'autre.
La solution 2 est suffisament light pour pouvoir être testé rapidement, et
pouvoir comparer les performances avec l'existant.
Si cela est Ok, alors la solution 2 peut être mise en production rapidement,
et la solution 1 (bien meilleure bien sûr) pourra être mise en oeuvre
ensuite (plus calmement).
Jacques.
"Nono" <fuckthespam@hotmail.com> a écrit dans le message de news:
3f950742$0$238$4d4eb98e@read.news.fr.uu.net...
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je
pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure
méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure
solution pour optmiser mon application, notamment en terme de temps de
réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql.
Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les
performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Mon avis subjectif : les 2 solutions ne sont pas exclusives l'une de l'autre.
La solution 2 est suffisament light pour pouvoir être testé rapidement, et pouvoir comparer les performances avec l'existant.
Si cela est Ok, alors la solution 2 peut être mise en production rapidement, et la solution 1 (bien meilleure bien sûr) pourra être mise en oeuvre ensuite (plus calmement).
Jacques.
"Nono" a écrit dans le message de news: 3f950742$0$238$
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure solution pour optmiser mon application, notamment en terme de temps de réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql. Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Merci de vos réponses
Arnaud
Dominique Peralta
Je ferais la même réponse que celle qui t'a été faite sur le NG Access. ;-) Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement passer ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La migration vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu souhaites voir les performances s'améliorer. Par contre, Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code. Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et malgré ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif, etc... (pour des applis client/serveur)
"Nono" a écrit dans le message de news:3f950742$0$238$
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure solution pour optmiser mon application, notamment en terme de temps de réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql. Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Merci de vos réponses
Arnaud
Je ferais la même réponse que celle qui t'a été faite sur le NG Access. ;-)
Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement passer
ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La migration
vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu
souhaites voir les performances s'améliorer. Par contre, Access sait
transformer une appli classique .mdb, en appli .adp, sans trop de modif de
code.
Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et malgré
ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès
natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense
qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif,
etc... (pour des applis client/serveur)
"Nono" <fuckthespam@hotmail.com> a écrit dans le message de
news:3f950742$0$238$4d4eb98e@read.news.fr.uu.net...
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je
pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure
méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure
solution pour optmiser mon application, notamment en terme de temps de
réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql.
Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les
performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Je ferais la même réponse que celle qui t'a été faite sur le NG Access. ;-) Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement passer ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La migration vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu souhaites voir les performances s'améliorer. Par contre, Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code. Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et malgré ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif, etc... (pour des applis client/serveur)
"Nono" a écrit dans le message de news:3f950742$0$238$
Bonjour,
j'ai un projet de migration d'une base access xp sur sql 2000.
le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je pense garder dans un premier temps le frontal access.
Pour répondre à ce critère de temps de réponse, quelle est la meilleure méthode :
1. migrer la base access en projet .adp et migrer toutes les données sur
le
serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
migration non négligeable dû à une réécriture importante du code (passage
de
DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure solution pour optmiser mon application, notamment en terme de temps de réponse.
2. Rester en base access (.mdb) et migrer les données sur le serveur sql. Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les performances sont largement inférieur à OLEDB.
Selon vous, quelle est la meilleure solution pour ma migration ?
Merci de vos réponses
Arnaud
Nono
Merci de ta réponse. Par contre, quand tu dis qu'Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai constaté en testant cette migration. Le fait de passer d'une base de données mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" a écrit dans le message de news:
Je ferais la même réponse que celle qui t'a été faite sur le NG Access.
;-)
Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement
passer
ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La
migration
vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu souhaites voir les performances s'améliorer. Par contre, Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code. Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et
malgré
ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif, etc... (pour des applis client/serveur)
"Nono" a écrit dans le message de news:3f950742$0$238$ > Bonjour, > > j'ai un projet de migration d'une base access xp sur sql 2000. > > le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je > pense garder dans un premier temps le frontal access. > > Pour répondre à ce critère de temps de réponse, quelle est la meilleure > méthode : > > 1. migrer la base access en projet .adp et migrer toutes les données sur le > serveur sql en tables, vues, ps, etc... : cette solution inclus un temps de > migration non négligeable dû à une réécriture importante du code
(passage
de > DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure > solution pour optmiser mon application, notamment en terme de temps de > réponse. > > 2. Rester en base access (.mdb) et migrer les données sur le serveur
sql.
> Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les > performances sont largement inférieur à OLEDB. > > Selon vous, quelle est la meilleure solution pour ma migration ? > > Merci de vos réponses > > Arnaud > >
Merci de ta réponse.
Par contre, quand tu dis qu'Access sait transformer une appli classique
.mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai
constaté en testant cette migration. Le fait de passer d'une base de données
mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où
réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" <NOSPAMdp@apnet.fr> a écrit dans le message de
news:OpV8Eh8lDHA.708@TK2MSFTNGP10.phx.gbl...
Je ferais la même réponse que celle qui t'a été faite sur le NG Access.
;-)
Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement
passer
ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La
migration
vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu
souhaites voir les performances s'améliorer. Par contre, Access sait
transformer une appli classique .mdb, en appli .adp, sans trop de modif de
code.
Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et
malgré
ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès
natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense
qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif,
etc... (pour des applis client/serveur)
"Nono" <fuckthespam@hotmail.com> a écrit dans le message de
news:3f950742$0$238$4d4eb98e@read.news.fr.uu.net...
> Bonjour,
>
> j'ai un projet de migration d'une base access xp sur sql 2000.
>
> le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je
> pense garder dans un premier temps le frontal access.
>
> Pour répondre à ce critère de temps de réponse, quelle est la meilleure
> méthode :
>
> 1. migrer la base access en projet .adp et migrer toutes les données sur
le
> serveur sql en tables, vues, ps, etc... : cette solution inclus un temps
de
> migration non négligeable dû à une réécriture importante du code
(passage
de
> DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure
> solution pour optmiser mon application, notamment en terme de temps de
> réponse.
>
> 2. Rester en base access (.mdb) et migrer les données sur le serveur
sql.
> Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les
> performances sont largement inférieur à OLEDB.
>
> Selon vous, quelle est la meilleure solution pour ma migration ?
>
> Merci de vos réponses
>
> Arnaud
>
>
Merci de ta réponse. Par contre, quand tu dis qu'Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai constaté en testant cette migration. Le fait de passer d'une base de données mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" a écrit dans le message de news:
Je ferais la même réponse que celle qui t'a été faite sur le NG Access.
;-)
Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement
passer
ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La
migration
vers SQL Server doit être accompagnée d'un passage en Client/Serveur si tu souhaites voir les performances s'améliorer. Par contre, Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code. Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et
malgré
ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je pense qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès natif, etc... (pour des applis client/serveur)
"Nono" a écrit dans le message de news:3f950742$0$238$ > Bonjour, > > j'ai un projet de migration d'une base access xp sur sql 2000. > > le critère n° 1 est d'avoir les meilleurs temps de reponse possible. je > pense garder dans un premier temps le frontal access. > > Pour répondre à ce critère de temps de réponse, quelle est la meilleure > méthode : > > 1. migrer la base access en projet .adp et migrer toutes les données sur le > serveur sql en tables, vues, ps, etc... : cette solution inclus un temps de > migration non négligeable dû à une réécriture importante du code
(passage
de > DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la meilleure > solution pour optmiser mon application, notamment en terme de temps de > réponse. > > 2. Rester en base access (.mdb) et migrer les données sur le serveur
sql.
> Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les > performances sont largement inférieur à OLEDB. > > Selon vous, quelle est la meilleure solution pour ma migration ? > > Merci de vos réponses > > Arnaud > >
Philippe Pham Minh
Bonjour,
Tout à fait d'accord La transformation d'un MDB en projet ADP implique une réécriture du code.
Philippe
"Nono" a écrit dans le message de news:3f9528ab$0$239$
Merci de ta réponse. Par contre, quand tu dis qu'Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai constaté en testant cette migration. Le fait de passer d'une base de
données
mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" a écrit dans le message de news: > Je ferais la même réponse que celle qui t'a été faite sur le NG Access. ;-) > Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement passer > ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La migration > vers SQL Server doit être accompagnée d'un passage en Client/Serveur si
tu
> souhaites voir les performances s'améliorer. Par contre, Access sait > transformer une appli classique .mdb, en appli .adp, sans trop de modif
de
> code. > Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et malgré > ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès > natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je
pense
> qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès
natif,
> etc... (pour des applis client/serveur) > > "Nono" a écrit dans le message de > news:3f950742$0$238$ > > Bonjour, > > > > j'ai un projet de migration d'une base access xp sur sql 2000. > > > > le critère n° 1 est d'avoir les meilleurs temps de reponse possible.
je
> > pense garder dans un premier temps le frontal access. > > > > Pour répondre à ce critère de temps de réponse, quelle est la
meilleure
> > méthode : > > > > 1. migrer la base access en projet .adp et migrer toutes les données
sur
> le > > serveur sql en tables, vues, ps, etc... : cette solution inclus un
temps
> de > > migration non négligeable dû à une réécriture importante du code (passage > de > > DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la
meilleure
> > solution pour optmiser mon application, notamment en terme de temps de > > réponse. > > > > 2. Rester en base access (.mdb) et migrer les données sur le serveur sql. > > Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les > > performances sont largement inférieur à OLEDB. > > > > Selon vous, quelle est la meilleure solution pour ma migration ? > > > > Merci de vos réponses > > > > Arnaud > > > > > > >
Bonjour,
Tout à fait d'accord
La transformation d'un MDB en projet ADP implique une réécriture du code.
Philippe
"Nono" <fuckthespam@hotmail.com> a écrit dans le message de
news:3f9528ab$0$239$4d4eb98e@read.news.fr.uu.net...
Merci de ta réponse.
Par contre, quand tu dis qu'Access sait transformer une appli classique
.mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai
constaté en testant cette migration. Le fait de passer d'une base de
données
mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où
réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" <NOSPAMdp@apnet.fr> a écrit dans le message de
news:OpV8Eh8lDHA.708@TK2MSFTNGP10.phx.gbl...
> Je ferais la même réponse que celle qui t'a été faite sur le NG Access.
;-)
> Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement
passer
> ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La
migration
> vers SQL Server doit être accompagnée d'un passage en Client/Serveur si
tu
> souhaites voir les performances s'améliorer. Par contre, Access sait
> transformer une appli classique .mdb, en appli .adp, sans trop de modif
de
> code.
> Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et
malgré
> ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès
> natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je
pense
> qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès
natif,
> etc... (pour des applis client/serveur)
>
> "Nono" <fuckthespam@hotmail.com> a écrit dans le message de
> news:3f950742$0$238$4d4eb98e@read.news.fr.uu.net...
> > Bonjour,
> >
> > j'ai un projet de migration d'une base access xp sur sql 2000.
> >
> > le critère n° 1 est d'avoir les meilleurs temps de reponse possible.
je
> > pense garder dans un premier temps le frontal access.
> >
> > Pour répondre à ce critère de temps de réponse, quelle est la
meilleure
> > méthode :
> >
> > 1. migrer la base access en projet .adp et migrer toutes les données
sur
> le
> > serveur sql en tables, vues, ps, etc... : cette solution inclus un
temps
> de
> > migration non négligeable dû à une réécriture importante du code
(passage
> de
> > DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la
meilleure
> > solution pour optmiser mon application, notamment en terme de temps de
> > réponse.
> >
> > 2. Rester en base access (.mdb) et migrer les données sur le serveur
sql.
> > Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les
> > performances sont largement inférieur à OLEDB.
> >
> > Selon vous, quelle est la meilleure solution pour ma migration ?
> >
> > Merci de vos réponses
> >
> > Arnaud
> >
> >
>
>
>
Tout à fait d'accord La transformation d'un MDB en projet ADP implique une réécriture du code.
Philippe
"Nono" a écrit dans le message de news:3f9528ab$0$239$
Merci de ta réponse. Par contre, quand tu dis qu'Access sait transformer une appli classique .mdb, en appli .adp, sans trop de modif de code, ce n'est pas ce que j'ai constaté en testant cette migration. Le fait de passer d'une base de
données
mdb en projet adp implique que l'on passe du code DAO en code ADO, d'où réécriture importante.
Es-tu d'accord avec moi ?
"Dominique Peralta" a écrit dans le message de news: > Je ferais la même réponse que celle qui t'a été faite sur le NG Access. ;-) > Quel que soit le langage, (Access, FoxPro, VB), le fait de simplement passer > ses datas de .mdb ou .dbf vers du SQL, ralentit l'application. La migration > vers SQL Server doit être accompagnée d'un passage en Client/Serveur si
tu
> souhaites voir les performances s'améliorer. Par contre, Access sait > transformer une appli classique .mdb, en appli .adp, sans trop de modif
de
> code. > Autrement, sous Foxpro, en Client/Serveur, je travaille avec ODBC, et malgré > ce que l'on peut en dire, ça marche très bien. Quand on voit que l'accès > natif WinDev pour SQL Server est plus lent qu'une connexion ODBC, je
pense
> qu'il faut se méfier des "on dit" concernant oledb, ado, dao, accès
natif,
> etc... (pour des applis client/serveur) > > "Nono" a écrit dans le message de > news:3f950742$0$238$ > > Bonjour, > > > > j'ai un projet de migration d'une base access xp sur sql 2000. > > > > le critère n° 1 est d'avoir les meilleurs temps de reponse possible.
je
> > pense garder dans un premier temps le frontal access. > > > > Pour répondre à ce critère de temps de réponse, quelle est la
meilleure
> > méthode : > > > > 1. migrer la base access en projet .adp et migrer toutes les données
sur
> le > > serveur sql en tables, vues, ps, etc... : cette solution inclus un
temps
> de > > migration non négligeable dû à une réécriture importante du code (passage > de > > DAO à ADO). Mais d'après les échos que j'ai pu avoir, c'est la
meilleure
> > solution pour optmiser mon application, notamment en terme de temps de > > réponse. > > > > 2. Rester en base access (.mdb) et migrer les données sur le serveur sql. > > Ensuite, utiliser un lien ODCB pour se connecter à SQL. A mon avis les > > performances sont largement inférieur à OLEDB. > > > > Selon vous, quelle est la meilleure solution pour ma migration ? > > > > Merci de vos réponses > > > > Arnaud > > > > > > >