Je souhaiterai faire le clair sur différents types d'accès aux données,
tachant d'être le plus précis possible dans mes explications.
Je précise que je suis sous Access 2000.
Je développe mes applications principalement de la manière suivante :
- j'ai une base de données .mdb dite "cliente", dans laquelle j'ai
uniquement des tables attachées, pointant vers une base de données dite
"serveur", à travers le réseau local.
Dans ce cas là, j'accède aux données via DAO 3.6. Le problème dans ce type
d'accès et d'architecture est les performances réduites lors de gros volumes
dans les tables. Cela s'expliquerait du fait que toutes les données des
tables impliquées dans une requête sont rappatriées sur le poste client
avant traitement de la requête (merci de me dire si je me trompe)
De ce fait, je migre petit à petit les applications lourdes en données vers
SQL Server (MSDE) pour la partie serveur. Cela est en effet bien plus
rapide, mais nécessite de réécrire les accès aux données en ADO.
J'ai alors pensé à un compromis : au lieu d'attacher mes tables vers un
fichier .mdb, pourquoi ne pas attacher mes tables avec des liens ODBC
(pointant vers un SQL Server) ? Cela m'éviterait alors peut être la
réécriture du code pour l'accès aux données ... non ? Puisque du point de
vue de la base cliente, la table existe toujours avec le même nom (sauf que
ça ne pointe au même endroit et vers la même chose).
Donc ma question est : est - ce aussi simple que ça ?
Et si ce n'est pas le cas, quelle est l'intérêt de programmer avec des
tables attachées ODBC par rapport à des accès en ADO ?
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
microsoft.access
Salut laurent,
j'ai aussi une grosse appli développée avec Access 2000 et qui foncitonne sur environ 160 sites industriels avec certaines bases contenant de gros volumes. le développement sous access n'est pas forcement associé a une lenteur. il y a des ratios de 1 a 10 pour la meme requete selon la methode de traitement (en dao). si tu fais faire tes requetes par le serveur et non par le poste client, genre tu crées un querydef temporaire sur le serveur que tu exécutes ensuite, trés peu (voir pas) de données remontent sur ton poste client et donc transite sur le réseau.
j'ai aussi une version de mon soft avec une base SQL Serveur et je me suis aussi posé la question ODBC et donc pas de réécriture puisqu'effectivement on peut conserver DAO ou alors changé le code (qui était pour mon cas composé principalement de SQL) et attaqué les données avec ADO. Ce que je fais (c'est encore en cours) en adaptant également le SQL (transac SQL). changement fais pour des questions de rapidité. Et théoriquement, cela devrait être aussi compatible avec d'autres bases.
salut philippe
LM wrote:
Bonsoir à tous,
Je souhaiterai faire le clair sur différents types d'accès aux donn ées, tachant d'être le plus précis possible dans mes explications.
Je précise que je suis sous Access 2000.
Je développe mes applications principalement de la manière suivante : - j'ai une base de données .mdb dite "cliente", dans laquelle j'ai uniquement des tables attachées, pointant vers une base de données di te "serveur", à travers le réseau local. Dans ce cas là, j'accède aux données via DAO 3.6. Le problème dan s ce type d'accès et d'architecture est les performances réduites lors de gros volumes dans les tables. Cela s'expliquerait du fait que toutes les données des tables impliquées dans une requête sont rappatriées sur le poste cl ient avant traitement de la requête (merci de me dire si je me trompe)
De ce fait, je migre petit à petit les applications lourdes en donnée s vers SQL Server (MSDE) pour la partie serveur. Cela est en effet bien plus rapide, mais nécessite de réécrire les accès aux données en ADO.
J'ai alors pensé à un compromis : au lieu d'attacher mes tables vers un fichier .mdb, pourquoi ne pas attacher mes tables avec des liens ODBC (pointant vers un SQL Server) ? Cela m'éviterait alors peut être la réécriture du code pour l'accès aux données ... non ? Puisque du point de vue de la base cliente, la table existe toujours avec le même nom (sauf que ça ne pointe au même endroit et vers la même chose).
Donc ma question est : est - ce aussi simple que ça ?
Et si ce n'est pas le cas, quelle est l'intérêt de programmer avec des tables attachées ODBC par rapport à des accès en ADO ?
En espérant avoir été assez précis ...
Merci d'avance !
Laurent
Salut laurent,
j'ai aussi une grosse appli développée avec Access 2000 et qui
foncitonne sur environ 160 sites industriels avec certaines bases
contenant de gros volumes. le développement sous access n'est pas
forcement associé a une lenteur. il y a des ratios de 1 a 10 pour la
meme requete selon la methode de traitement (en dao).
si tu fais faire tes requetes par le serveur et non par le poste
client, genre tu crées un querydef temporaire sur le serveur que tu
exécutes ensuite, trés peu (voir pas) de données remontent sur ton
poste client et donc transite sur le réseau.
j'ai aussi une version de mon soft avec une base SQL Serveur et je me
suis aussi posé la question ODBC et donc pas de réécriture
puisqu'effectivement on peut conserver DAO ou alors changé le code
(qui était pour mon cas composé principalement de SQL)
et attaqué les données avec ADO. Ce que je fais (c'est encore en
cours) en adaptant également le SQL (transac SQL). changement fais
pour des questions de rapidité. Et théoriquement, cela devrait être
aussi compatible avec d'autres bases.
salut
philippe
LM wrote:
Bonsoir à tous,
Je souhaiterai faire le clair sur différents types d'accès aux donn ées,
tachant d'être le plus précis possible dans mes explications.
Je précise que je suis sous Access 2000.
Je développe mes applications principalement de la manière suivante :
- j'ai une base de données .mdb dite "cliente", dans laquelle j'ai
uniquement des tables attachées, pointant vers une base de données di te
"serveur", à travers le réseau local.
Dans ce cas là, j'accède aux données via DAO 3.6. Le problème dan s ce type
d'accès et d'architecture est les performances réduites lors de gros volumes
dans les tables. Cela s'expliquerait du fait que toutes les données des
tables impliquées dans une requête sont rappatriées sur le poste cl ient
avant traitement de la requête (merci de me dire si je me trompe)
De ce fait, je migre petit à petit les applications lourdes en donnée s vers
SQL Server (MSDE) pour la partie serveur. Cela est en effet bien plus
rapide, mais nécessite de réécrire les accès aux données en ADO.
J'ai alors pensé à un compromis : au lieu d'attacher mes tables vers un
fichier .mdb, pourquoi ne pas attacher mes tables avec des liens ODBC
(pointant vers un SQL Server) ? Cela m'éviterait alors peut être la
réécriture du code pour l'accès aux données ... non ? Puisque du point de
vue de la base cliente, la table existe toujours avec le même nom (sauf que
ça ne pointe au même endroit et vers la même chose).
Donc ma question est : est - ce aussi simple que ça ?
Et si ce n'est pas le cas, quelle est l'intérêt de programmer avec des
tables attachées ODBC par rapport à des accès en ADO ?
j'ai aussi une grosse appli développée avec Access 2000 et qui foncitonne sur environ 160 sites industriels avec certaines bases contenant de gros volumes. le développement sous access n'est pas forcement associé a une lenteur. il y a des ratios de 1 a 10 pour la meme requete selon la methode de traitement (en dao). si tu fais faire tes requetes par le serveur et non par le poste client, genre tu crées un querydef temporaire sur le serveur que tu exécutes ensuite, trés peu (voir pas) de données remontent sur ton poste client et donc transite sur le réseau.
j'ai aussi une version de mon soft avec une base SQL Serveur et je me suis aussi posé la question ODBC et donc pas de réécriture puisqu'effectivement on peut conserver DAO ou alors changé le code (qui était pour mon cas composé principalement de SQL) et attaqué les données avec ADO. Ce que je fais (c'est encore en cours) en adaptant également le SQL (transac SQL). changement fais pour des questions de rapidité. Et théoriquement, cela devrait être aussi compatible avec d'autres bases.
salut philippe
LM wrote:
Bonsoir à tous,
Je souhaiterai faire le clair sur différents types d'accès aux donn ées, tachant d'être le plus précis possible dans mes explications.
Je précise que je suis sous Access 2000.
Je développe mes applications principalement de la manière suivante : - j'ai une base de données .mdb dite "cliente", dans laquelle j'ai uniquement des tables attachées, pointant vers une base de données di te "serveur", à travers le réseau local. Dans ce cas là, j'accède aux données via DAO 3.6. Le problème dan s ce type d'accès et d'architecture est les performances réduites lors de gros volumes dans les tables. Cela s'expliquerait du fait que toutes les données des tables impliquées dans une requête sont rappatriées sur le poste cl ient avant traitement de la requête (merci de me dire si je me trompe)
De ce fait, je migre petit à petit les applications lourdes en donnée s vers SQL Server (MSDE) pour la partie serveur. Cela est en effet bien plus rapide, mais nécessite de réécrire les accès aux données en ADO.
J'ai alors pensé à un compromis : au lieu d'attacher mes tables vers un fichier .mdb, pourquoi ne pas attacher mes tables avec des liens ODBC (pointant vers un SQL Server) ? Cela m'éviterait alors peut être la réécriture du code pour l'accès aux données ... non ? Puisque du point de vue de la base cliente, la table existe toujours avec le même nom (sauf que ça ne pointe au même endroit et vers la même chose).
Donc ma question est : est - ce aussi simple que ça ?
Et si ce n'est pas le cas, quelle est l'intérêt de programmer avec des tables attachées ODBC par rapport à des accès en ADO ?
