Access en réseau (sql server, DAO, Access 2000 & 2002)
4 réponses
quasimodo
Bonjour,
Je suis occup=E9 =E0 migrer une application r=E9seau MS Access 2000 & 2002
vers un syst=E8me utilisant SQL Server.
Les contraintes sont : utilisation uniquement du DAO, Run time Access
sur les postes client, SGBDR distant (wan - ligne lou=E9e).
Mes questions :
1=2E J'aimerais limiter le traffique r=E9seau.
2=2E Avoir de bonnes performances sur les postes clients (wk2 et p4).
Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois
=E9viter les mise =E0 jour du type application.currentdb.execute
"[insert]/[update]/[delete] ..."(-> g=E9n=E9ration de traffiques) et
plut=F4t utiliser soit des stored proc en passant des param=E8tres ou
ouvrir des recordset et faire des mise =E0 jour local. Mais je pense
qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font
en temps +- r=E9el, soit apr=E8s l'instruction explicite
recordset.update, ce qui est =E9quivalant =E0
application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous
avez de l'exp=E9riences dans ce domaines ou des infos, je suis preneur.
Un tr=E8s grand merci d'avance =E0 vous.
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
J-Pierre
Bonjour,
Avant de te répondre, quelques précisions supplémentaires:
Combien de clients Access prévois-tu ? Pourquoi utiliser uniquement du DAO ? Quel débit (vitesse) pour ton wan ?
"quasimodo" a écrit dans le message de news: Bonjour, Je suis occupé à migrer une application réseau MS Access 2000 & 2002 vers un système utilisant SQL Server. Les contraintes sont : utilisation uniquement du DAO, Run time Access sur les postes client, SGBDR distant (wan - ligne louée). Mes questions : 1. J'aimerais limiter le traffique réseau. 2. Avoir de bonnes performances sur les postes clients (wk2 et p4). Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois éviter les mise à jour du type application.currentdb.execute "[insert]/[update]/[delete] ..."(-> génération de traffiques) et plutôt utiliser soit des stored proc en passant des paramètres ou ouvrir des recordset et faire des mise à jour local. Mais je pense qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font en temps +- réel, soit après l'instruction explicite recordset.update, ce qui est équivalant à application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous avez de l'expériences dans ce domaines ou des infos, je suis preneur. Un très grand merci d'avance à vous.
Q.
Bonjour,
Avant de te répondre, quelques précisions supplémentaires:
Combien de clients Access prévois-tu ?
Pourquoi utiliser uniquement du DAO ?
Quel débit (vitesse) pour ton wan ?
"quasimodo" <wild_riki@yahoo.fr> a écrit dans le message de news: 1118689950.517740.295210@o13g2000cwo.googlegroups.com...
Bonjour,
Je suis occupé à migrer une application réseau MS Access 2000 & 2002
vers un système utilisant SQL Server.
Les contraintes sont : utilisation uniquement du DAO, Run time Access
sur les postes client, SGBDR distant (wan - ligne louée).
Mes questions :
1. J'aimerais limiter le traffique réseau.
2. Avoir de bonnes performances sur les postes clients (wk2 et p4).
Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois
éviter les mise à jour du type application.currentdb.execute
"[insert]/[update]/[delete] ..."(-> génération de traffiques) et
plutôt utiliser soit des stored proc en passant des paramètres ou
ouvrir des recordset et faire des mise à jour local. Mais je pense
qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font
en temps +- réel, soit après l'instruction explicite
recordset.update, ce qui est équivalant à
application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous
avez de l'expériences dans ce domaines ou des infos, je suis preneur.
Un très grand merci d'avance à vous.
Avant de te répondre, quelques précisions supplémentaires:
Combien de clients Access prévois-tu ? Pourquoi utiliser uniquement du DAO ? Quel débit (vitesse) pour ton wan ?
"quasimodo" a écrit dans le message de news: Bonjour, Je suis occupé à migrer une application réseau MS Access 2000 & 2002 vers un système utilisant SQL Server. Les contraintes sont : utilisation uniquement du DAO, Run time Access sur les postes client, SGBDR distant (wan - ligne louée). Mes questions : 1. J'aimerais limiter le traffique réseau. 2. Avoir de bonnes performances sur les postes clients (wk2 et p4). Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois éviter les mise à jour du type application.currentdb.execute "[insert]/[update]/[delete] ..."(-> génération de traffiques) et plutôt utiliser soit des stored proc en passant des paramètres ou ouvrir des recordset et faire des mise à jour local. Mais je pense qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font en temps +- réel, soit après l'instruction explicite recordset.update, ce qui est équivalant à application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous avez de l'expériences dans ce domaines ou des infos, je suis preneur. Un très grand merci d'avance à vous.
Q.
Sylvain Lafontaine
Wow! DAO sur le WAN! Est-ce que vos clients sont des tibétains désireux d'atteindre le Nirvana par une contemplation assidue du Saint-Écran?
Si vos formulaires ne sont pas trop compliqués et que vous désirez utiliser les tables liées ODBC d'Access, une utilisation exhaustive des Views va permettre de régler plusieurs des problèmes de vitesse prévisibles de cette configuration: http://support.microsoft.com/kb/q209123/ .
Dans le cas contraire, allez-y avec des formulaires non-liés et occupez-vous de gérer vous-même les mise-à-jour. Au point de vue traffic, il n'y a pas vraiment de différence entre une procédure stockée et un appel à currentdb.execute. La faveur des PS tient plutôt à une petite baisse de la charge de travail sur le serveur (à cause de la pré-compilation des PS) et à la possibilité de gérer un peu mieux la sécurité au niveau du serveur.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"quasimodo" wrote in message news: Bonjour, Je suis occupé à migrer une application réseau MS Access 2000 & 2002 vers un système utilisant SQL Server. Les contraintes sont : utilisation uniquement du DAO, Run time Access sur les postes client, SGBDR distant (wan - ligne louée). Mes questions : 1. J'aimerais limiter le traffique réseau. 2. Avoir de bonnes performances sur les postes clients (wk2 et p4). Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois éviter les mise à jour du type application.currentdb.execute "[insert]/[update]/[delete] ..."(-> génération de traffiques) et plutôt utiliser soit des stored proc en passant des paramètres ou ouvrir des recordset et faire des mise à jour local. Mais je pense qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font en temps +- réel, soit après l'instruction explicite recordset.update, ce qui est équivalant à application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous avez de l'expériences dans ce domaines ou des infos, je suis preneur. Un très grand merci d'avance à vous.
Q.
Wow! DAO sur le WAN! Est-ce que vos clients sont des tibétains désireux
d'atteindre le Nirvana par une contemplation assidue du Saint-Écran?
Si vos formulaires ne sont pas trop compliqués et que vous désirez utiliser
les tables liées ODBC d'Access, une utilisation exhaustive des Views va
permettre de régler plusieurs des problèmes de vitesse prévisibles de cette
configuration: http://support.microsoft.com/kb/q209123/ .
Dans le cas contraire, allez-y avec des formulaires non-liés et occupez-vous
de gérer vous-même les mise-à-jour. Au point de vue traffic, il n'y a pas
vraiment de différence entre une procédure stockée et un appel à
currentdb.execute. La faveur des PS tient plutôt à une petite baisse de la
charge de travail sur le serveur (à cause de la pré-compilation des PS) et à
la possibilité de gérer un peu mieux la sécurité au niveau du serveur.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"quasimodo" <wild_riki@yahoo.fr> wrote in message
news:1118689950.517740.295210@o13g2000cwo.googlegroups.com...
Bonjour,
Je suis occupé à migrer une application réseau MS Access 2000 & 2002
vers un système utilisant SQL Server.
Les contraintes sont : utilisation uniquement du DAO, Run time Access
sur les postes client, SGBDR distant (wan - ligne louée).
Mes questions :
1. J'aimerais limiter le traffique réseau.
2. Avoir de bonnes performances sur les postes clients (wk2 et p4).
Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois
éviter les mise à jour du type application.currentdb.execute
"[insert]/[update]/[delete] ..."(-> génération de traffiques) et
plutôt utiliser soit des stored proc en passant des paramètres ou
ouvrir des recordset et faire des mise à jour local. Mais je pense
qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font
en temps +- réel, soit après l'instruction explicite
recordset.update, ce qui est équivalant à
application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous
avez de l'expériences dans ce domaines ou des infos, je suis preneur.
Un très grand merci d'avance à vous.
Wow! DAO sur le WAN! Est-ce que vos clients sont des tibétains désireux d'atteindre le Nirvana par une contemplation assidue du Saint-Écran?
Si vos formulaires ne sont pas trop compliqués et que vous désirez utiliser les tables liées ODBC d'Access, une utilisation exhaustive des Views va permettre de régler plusieurs des problèmes de vitesse prévisibles de cette configuration: http://support.microsoft.com/kb/q209123/ .
Dans le cas contraire, allez-y avec des formulaires non-liés et occupez-vous de gérer vous-même les mise-à-jour. Au point de vue traffic, il n'y a pas vraiment de différence entre une procédure stockée et un appel à currentdb.execute. La faveur des PS tient plutôt à une petite baisse de la charge de travail sur le serveur (à cause de la pré-compilation des PS) et à la possibilité de gérer un peu mieux la sécurité au niveau du serveur.
-- Sylvain Lafontaine, ing. MVP - Technologies Virtual-PC E-mail: http://cerbermail.com/?QugbLEWINF
"quasimodo" wrote in message news: Bonjour, Je suis occupé à migrer une application réseau MS Access 2000 & 2002 vers un système utilisant SQL Server. Les contraintes sont : utilisation uniquement du DAO, Run time Access sur les postes client, SGBDR distant (wan - ligne louée). Mes questions : 1. J'aimerais limiter le traffique réseau. 2. Avoir de bonnes performances sur les postes clients (wk2 et p4). Pouvez-vous me dire ce qui est le plus performant. Je pense que je dois éviter les mise à jour du type application.currentdb.execute "[insert]/[update]/[delete] ..."(-> génération de traffiques) et plutôt utiliser soit des stored proc en passant des paramètres ou ouvrir des recordset et faire des mise à jour local. Mais je pense qu'il n'y a pas comme en ado de batchupdate. Donc, les updates se font en temps +- réel, soit après l'instruction explicite recordset.update, ce qui est équivalant à application.currentdb.execute "[insert]/[update]/[delete] ...". Si vous avez de l'expériences dans ce domaines ou des infos, je suis preneur. Un très grand merci d'avance à vous.
Q.
quasimodo
Bonjour, +- 10 à 15 clients. Je veux éviter de recoder l'ensemble du projet qui est fait sous dao. Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats (exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A part, de passer sous ado? Merci.
Cordialement,
Q.
Bonjour,
+- 10 à 15 clients.
Je veux éviter de recoder l'ensemble du projet qui est fait sous dao.
Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats
(exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A
part, de passer sous ado?
Merci.
Bonjour, +- 10 à 15 clients. Je veux éviter de recoder l'ensemble du projet qui est fait sous dao. Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats (exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A part, de passer sous ado? Merci.
Cordialement,
Q.
J-Pierre
Bonjour,
Tu peux effectivement utiliser les tables liées d'Access et ne rien toucher à ton appli. Mais tu vas sans doute au devant de gros problèmes de performance. La solution idéale, mais malheureusement assez lourde à mettre en oeuvre, est de convertir ton appli en projet ADP. Pourquoi ?
Access ne suit pas les règles client-serveur de SQL, il a été développé par MS pour permettre aux non-informaticiens de développer des appli de manière simple et conviviale. Et aussi en tablant sur le fait que les tables ne sont jamais très grosses, qu'il n'y a jamais beaucoup d'utilisateurs, que le réseau local est très rapide, et que donc un transfer important d'informations ne pénalise pas vraiment l'utilisateur.
Tiens, un exemple du non-respect des règles SQL: Comme source d'un formulaire, tu as 2 tables, quelque chose comme: SELECT matable1.*, matable2.* FROM matable1 LEFT JOIN matable2 ON blablabla WHERE blablabla. Avec Access, tu peux allègrement mélanger les champs des 2 tables dans ce seul formulaire et les mettre à jour. Avec SQL (et ADP) , tu devras faire 2 sous-formulaires, un pour chaque table, car une instruction UPDATE ne peut mettre à jour qu'une seule table à la fois.
Convertir du code DAO en ADO n'est pas vraiment un problème, plutôt une moulinette. Pour la performance, les MAJ en temps réel non plus, sauf bien sûr si tu mets à jour beaucoup de lignes dans une seule transaction.
Ton vrai problème est dans la conception des formulaires et états. Prenons un exemple simple: Tu as une table avec quelques milliers de lignes et un formulaire en mode unique dont la source est "Select * from matable", en clair, tu as pris la table comme source. Quelque chose finalement d'assez banal.
Quand tu ouvres ton formulaire, Access affiche immédiatement la première ligne de ta table et CONTINUE à lire les lignes pour créer son RecordSet. Toi, tu ne te rends même pas compte que le traitement continue. Si tu passes en SQL sur un serveur distant sans rien changer, tu vas créer une charge insupportable pour le serveur et le réseau parce que toute ta table va être transférée entre le serveur et le client. Toi, tu ne t'en rendras sans doute toujours pas compte, mais les autres utilisateurs vont souffrir.......
Et puis, il y a tout le reste, les procédures stockées, les triggers (déclencheurs ?), qui ont aussi l'immense avantage de faciliter le développement et la maintenance de l'appli (pas de code redondant dans les formulaires ou les modules).
J-Pierre
"quasimodo" a écrit dans le message de news: Bonjour, +- 10 à 15 clients. Je veux éviter de recoder l'ensemble du projet qui est fait sous dao. Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats (exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A part, de passer sous ado? Merci.
Cordialement,
Q.
Bonjour,
Tu peux effectivement utiliser les tables liées d'Access et ne rien toucher à ton appli. Mais tu vas sans doute au devant de
gros problèmes de performance. La solution idéale, mais malheureusement assez lourde à mettre en oeuvre, est de convertir ton
appli en projet ADP. Pourquoi ?
Access ne suit pas les règles client-serveur de SQL, il a été développé par MS pour permettre aux non-informaticiens de
développer des appli de manière simple et conviviale. Et aussi en tablant sur le fait que les tables ne sont jamais très
grosses, qu'il n'y a jamais beaucoup d'utilisateurs, que le réseau local est très rapide, et que donc un transfer important
d'informations ne pénalise pas vraiment l'utilisateur.
Tiens, un exemple du non-respect des règles SQL: Comme source d'un formulaire, tu as 2 tables, quelque chose comme: SELECT
matable1.*, matable2.* FROM matable1 LEFT JOIN matable2 ON blablabla WHERE blablabla. Avec Access, tu peux allègrement
mélanger les champs des 2 tables dans ce seul formulaire et les mettre à jour. Avec SQL (et ADP) , tu devras faire 2
sous-formulaires, un pour chaque table, car une instruction UPDATE ne peut mettre à jour qu'une seule table à la fois.
Convertir du code DAO en ADO n'est pas vraiment un problème, plutôt une moulinette. Pour la performance, les MAJ en temps réel
non plus, sauf bien sûr si tu mets à jour beaucoup de lignes dans une seule transaction.
Ton vrai problème est dans la conception des formulaires et états. Prenons un exemple simple: Tu as une table avec quelques
milliers de lignes et un formulaire en mode unique dont la source est "Select * from matable", en clair, tu as pris la table
comme source. Quelque chose finalement d'assez banal.
Quand tu ouvres ton formulaire, Access affiche immédiatement la première ligne de ta table et CONTINUE à lire les lignes pour
créer son RecordSet. Toi, tu ne te rends même pas compte que le traitement continue. Si tu passes en SQL sur un serveur
distant sans rien changer, tu vas créer une charge insupportable pour le serveur et le réseau parce que toute ta table va être
transférée entre le serveur et le client. Toi, tu ne t'en rendras sans doute toujours pas compte, mais les autres utilisateurs
vont souffrir.......
Et puis, il y a tout le reste, les procédures stockées, les triggers (déclencheurs ?), qui ont aussi l'immense avantage de
faciliter le développement et la maintenance de l'appli (pas de code redondant dans les formulaires ou les modules).
J-Pierre
"quasimodo" <wild_riki@yahoo.fr> a écrit dans le message de news: 1118733648.755372.320510@g47g2000cwa.googlegroups.com...
Bonjour,
+- 10 à 15 clients.
Je veux éviter de recoder l'ensemble du projet qui est fait sous dao.
Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats
(exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A
part, de passer sous ado?
Merci.
Tu peux effectivement utiliser les tables liées d'Access et ne rien toucher à ton appli. Mais tu vas sans doute au devant de gros problèmes de performance. La solution idéale, mais malheureusement assez lourde à mettre en oeuvre, est de convertir ton appli en projet ADP. Pourquoi ?
Access ne suit pas les règles client-serveur de SQL, il a été développé par MS pour permettre aux non-informaticiens de développer des appli de manière simple et conviviale. Et aussi en tablant sur le fait que les tables ne sont jamais très grosses, qu'il n'y a jamais beaucoup d'utilisateurs, que le réseau local est très rapide, et que donc un transfer important d'informations ne pénalise pas vraiment l'utilisateur.
Tiens, un exemple du non-respect des règles SQL: Comme source d'un formulaire, tu as 2 tables, quelque chose comme: SELECT matable1.*, matable2.* FROM matable1 LEFT JOIN matable2 ON blablabla WHERE blablabla. Avec Access, tu peux allègrement mélanger les champs des 2 tables dans ce seul formulaire et les mettre à jour. Avec SQL (et ADP) , tu devras faire 2 sous-formulaires, un pour chaque table, car une instruction UPDATE ne peut mettre à jour qu'une seule table à la fois.
Convertir du code DAO en ADO n'est pas vraiment un problème, plutôt une moulinette. Pour la performance, les MAJ en temps réel non plus, sauf bien sûr si tu mets à jour beaucoup de lignes dans une seule transaction.
Ton vrai problème est dans la conception des formulaires et états. Prenons un exemple simple: Tu as une table avec quelques milliers de lignes et un formulaire en mode unique dont la source est "Select * from matable", en clair, tu as pris la table comme source. Quelque chose finalement d'assez banal.
Quand tu ouvres ton formulaire, Access affiche immédiatement la première ligne de ta table et CONTINUE à lire les lignes pour créer son RecordSet. Toi, tu ne te rends même pas compte que le traitement continue. Si tu passes en SQL sur un serveur distant sans rien changer, tu vas créer une charge insupportable pour le serveur et le réseau parce que toute ta table va être transférée entre le serveur et le client. Toi, tu ne t'en rendras sans doute toujours pas compte, mais les autres utilisateurs vont souffrir.......
Et puis, il y a tout le reste, les procédures stockées, les triggers (déclencheurs ?), qui ont aussi l'immense avantage de faciliter le développement et la maintenance de l'appli (pas de code redondant dans les formulaires ou les modules).
J-Pierre
"quasimodo" a écrit dans le message de news: Bonjour, +- 10 à 15 clients. Je veux éviter de recoder l'ensemble du projet qui est fait sous dao. Mais bon, peux t'on passer en dao odbc ou rdo avec de bon résultats (exemples ou doc sont bien venus)? sinon, que me conseillez-vous? A part, de passer sous ado? Merci.
