Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office Access DAO - ADO - Accès aux enregistrements

DAO - ADO - Accès aux enregistrements

3 réponses
Avatar
Santino
Bonjour à tous,

Je vais certainement aborder un sujet plusieurs fois débattu,
cependant, malgré le fait d'avoir lu pas mal de tutoriaux, j'ai encore
besoin de quelques éclaircissements ...

Aujourd'hui, j'ai développé pas mal d'applications Access qui remplissent
convenablement leur rôle. Cependant, avec l'évolution de celles ci, et la
multiplicité des utilisateurs, les ralentissements commencent à se faire
sentir.

Bref rappel de mon architecture :
Une base Access en local sur le poste, possédant des tables liées
pointant vers une base "serveur", tous les clients pointant vers cette base.

J'utilise DAO pour ajouter des enregistrements, avec la méthode AddNew, et
je les met à jour avec la méthode Edit. Sur ces points, je pense que c'est
propre.

Par contre, là où je pense que c'est moins bon, c'est dans la restitution de
données. En effet, par exemple, j'utilise Me.RecordSource = "SELECT .... "
pour remplir un état. Et j'ai l'impression que cela est très pénalisant,
dans la mesure où tant que l'état est ouvert, le recordset est maintenu sur
la table. Ce qui fait que ça ralenti énormément si quelqu'un veut aussi
requêter sur cette table. Est ce que je me trompe ?

J'ai donc par un moment pensé à rappatrier d'abord localement les données
sur la base locale, puis requêter sur ces tables locales. Mais ça me paraît
plus lourd à gérer ... Cependant si c'est la solution ...

De même, dans mes formulaires, pour les zones de liste, je les alimente en
données avec une chaîne SQL. Et là aussi, même effet, ça "maintient" un
recordset sur la table tant que le formulaire est ouvert ...


En somme :
Si je reste avec mon architecture (Access en client serveur + DAO), quelle
est la bonne méthode à utliser afin de na pas bloquer des recordsets sur les
tables ?

Ais je intérêt à passer en ADO, avec un serveur MSDE par exemple ?

Et pouvez vous me confirmer que :
- DAO permet l'accès aux données seulement si on est en Access côté
"serveur"
- ADO n'a d'intérêt que si on utlise un SGBDR type SQL Server, Sybase,MySQL,
Oracle ...
- En ADO, vaut il mieux passer par un DSN ODBC, et attacher les tables dans
la base client, ou bien écrire les chaînes de connexion "à la main" sans DSN
ODBC
- Un DSN est il nécessairement une connexion ODBC ?

D'avance un grand merci ...

Laurent
Signaler un problème avec ce contenu

3 réponses

Supprimer
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
Avatar
Buddy
Bonjour à tous,
Salut


J'utilise DAO pour ajouter des enregistrements, avec la méthode AddNew, et je les met à jour avec
la méthode Edit. Sur ces points, je pense que c'est propre.
J'utiliserai plutôt une requête SQL du genre INSERT INTO ou UPDATE à la place de .AddNew ou .Edit,

le SQL est bien plus performant d'une part et d'autre part si tu passes sur serveur de type SGBDR
là le SQL est obligatoire sinon t'as aucun intérêt à migrer.


Par contre, là où je pense que c'est moins bon, c'est dans la restitution de données. En effet,
par exemple, j'utilise Me.RecordSource = "SELECT .... " pour remplir un état. Et j'ai
l'impression que cela est très pénalisant, dans la mesure où tant que l'état est ouvert, le
recordset est maintenu sur la table. Ce qui fait que ça ralenti énormément si quelqu'un veut
aussi requêter sur cette table. Est ce que je me trompe ?
Non, le problème avec Access, c'est que à chaque fois que tu extraits des données d'une base

distante, le moteur Jet te renvoie la totalité des données et ensuite il exécute en local tes
sélections. A l'inverse avec un serveur de type SGDBR en ADO, le serveur te renvoie juste ce dont
tu as besoin en gros ne passe sur le réseau que le résultat de ton SELECT. Je te fais pas dire
l'écart des performances.


J'ai donc par un moment pensé à rappatrier d'abord localement les données sur la base locale,
puis requêter sur ces tables locales. Mais ça me paraît plus lourd à gérer ... Cependant si c'est
la solution ...
Trop fastidieux et bonjour l'usine à gaz ! Et puis si tu rapatrie tes données en local, comment tu

vas suivre les mises à jour faites par les autres utilisateurs ?


De même, dans mes formulaires, pour les zones de liste, je les alimente en données avec une
chaîne SQL. Et là aussi, même effet, ça "maintient" un recordset sur la table tant que le
formulaire est ouvert ...
Si tu passe sur SGBDR, tes temps de réponse seront incomparables.


En somme :
Si je reste avec mon architecture (Access en client serveur + DAO), quelle est la bonne méthode à
utliser afin de na pas bloquer des recordsets sur les tables ?
Mais tu ne vas pas rester avec ton architecture, rêves pas. Tu n'auras jamais des temps de réponse

acceptables avec Access serveur.


Ais je intérêt à passer en ADO, avec un serveur MSDE par exemple ?
A ton avis ??? :')


Et pouvez vous me confirmer que :
- DAO permet l'accès aux données seulement si on est en Access côté "serveur"
DAO est en fin de règne, à ce rythme il ne va plus permettre grand chose


- ADO n'a d'intérêt que si on utlise un SGBDR type SQL Server, Sybase,MySQL, Oracle ...
En général la règle est simple : DAO quand c'est access et ADO pour tout le reste.


- En ADO, vaut il mieux passer par un DSN ODBC, et attacher les tables dans la base client, ou
bien écrire les chaînes de connexion "à la main" sans DSN ODBC
Il faudra créer un DSN système (accessible par tous les utilisateurs de l'ordinateur) sur chaque

machine qui pointeras vers ton serveur et ta base.
La gestion d'une connexion basée sur un DSN c'est plus simple.
L'idéal c'est une connexion dite DSN-Less avec une chaine de connexion propre au serveur que tu
choisiras. Il en existe des tas.

- Un DSN est il nécessairement une connexion ODBC ?
Oui.


D'avance un grand merci ...

Laurent



--
Ouala
Bye
Buddy

PS : retirer 123 pour m'envoyer un email.

Avatar
Laurent Merlet
Salut Buddy,

Merci pour tes réponses, ça me satisfait !
Par contre, sur un point je ne trouve pas ça très clair, voir plus bas :


"Buddy" a écrit dans le message de
news:
Bonjour à tous,
Salut


J'utilise DAO pour ajouter des enregistrements, avec la méthode AddNew,
et je les met à jour avec


la méthode Edit. Sur ces points, je pense que c'est propre.
J'utiliserai plutôt une requête SQL du genre INSERT INTO ou UPDATE à la

place de .AddNew ou .Edit,

le SQL est bien plus performant d'une part et d'autre part si tu passes
sur serveur de type SGBDR

là le SQL est obligatoire sinon t'as aucun intérêt à migrer.


Par contre, là où je pense que c'est moins bon, c'est dans la
restitution de données. En effet,


par exemple, j'utilise Me.RecordSource = "SELECT .... " pour remplir un
état. Et j'ai


l'impression que cela est très pénalisant, dans la mesure où tant que
l'état est ouvert, le


recordset est maintenu sur la table. Ce qui fait que ça ralenti
énormément si quelqu'un veut


aussi requêter sur cette table. Est ce que je me trompe ?
Non, le problème avec Access, c'est que à chaque fois que tu extraits des

données d'une base

distante, le moteur Jet te renvoie la totalité des données et ensuite il
exécute en local tes

sélections. A l'inverse avec un serveur de type SGDBR en ADO, le serveur
te renvoie juste ce dont

tu as besoin en gros ne passe sur le réseau que le résultat de ton SELECT.
Je te fais pas dire

l'écart des performances.


Voila : tu dis que le problème vient du fait que Jet doit récupérer
l'intégralité de la table en local pour traiter la requête, sur ce point ok.
Mais ce n'était pas mon problème de base. Moi je disais que si quelqu'un
avait par exemple un état d'ouvert à l'écran (depuis 5 minutes par exemple),
les accès pour un autre utlissateur sur un autre poste, se trouvaient très
ralentis. En cela je ne vois pas en quoi le fait que l'intégralité de la
table soit rappatriée en local mette plus de temps si quelqu'un a déjà
accédé à la table (et par là j'entend que le transfert de l'intégralité de
la table a été terminé depuis plusieurs minutes) ou pas.
Peut être pour illustrer mieux ma question : tu sais quand quelqu'un ouvre
un état dont les données sont puisées sur une base 'serveur', il y a un
fichier .ldb qui se créé. Et bien quand l'état est fermé par le client, le
fichier .ldb est supprimé. Je sais à quoi correpond le fichier .ldb, mais
j'avais donc l'impression que de maintenir l'état ouvert 'bloquait' en qq
sorte des accès concurrents ou tout du moins les ralentissait fortement, en
tout cas c'est ce que j'ai constaté... et donc le fait que les données
soient rappatriées en local n'explique pas ces ralentissements.



J'ai donc par un moment pensé à rappatrier d'abord localement les
données sur la base locale,


puis requêter sur ces tables locales. Mais ça me paraît plus lourd à
gérer ... Cependant si c'est


la solution ...
Trop fastidieux et bonjour l'usine à gaz ! Et puis si tu rapatrie tes

données en local, comment tu

vas suivre les mises à jour faites par les autres utilisateurs ?


De même, dans mes formulaires, pour les zones de liste, je les alimente
en données avec une


chaîne SQL. Et là aussi, même effet, ça "maintient" un recordset sur la
table tant que le


formulaire est ouvert ...
Si tu passe sur SGBDR, tes temps de réponse seront incomparables.


En somme :
Si je reste avec mon architecture (Access en client serveur + DAO),
quelle est la bonne méthode à


utliser afin de na pas bloquer des recordsets sur les tables ?
Mais tu ne vas pas rester avec ton architecture, rêves pas. Tu n'auras

jamais des temps de réponse

acceptables avec Access serveur.


Ais je intérêt à passer en ADO, avec un serveur MSDE par exemple ?
A ton avis ??? :')


Et pouvez vous me confirmer que :
- DAO permet l'accès aux données seulement si on est en Access côté
"serveur"


DAO est en fin de règne, à ce rythme il ne va plus permettre grand chose

- ADO n'a d'intérêt que si on utlise un SGBDR type SQL Server,
Sybase,MySQL, Oracle ...


En général la règle est simple : DAO quand c'est access et ADO pour tout
le reste.


- En ADO, vaut il mieux passer par un DSN ODBC, et attacher les tables
dans la base client, ou


bien écrire les chaînes de connexion "à la main" sans DSN ODBC
Il faudra créer un DSN système (accessible par tous les utilisateurs de

l'ordinateur) sur chaque

machine qui pointeras vers ton serveur et ta base.
La gestion d'une connexion basée sur un DSN c'est plus simple.
L'idéal c'est une connexion dite DSN-Less avec une chaine de connexion
propre au serveur que tu

choisiras. Il en existe des tas.

- Un DSN est il nécessairement une connexion ODBC ?
Oui.


D'avance un grand merci ...

Laurent



--
Ouala
Bye
Buddy

PS : retirer 123 pour m'envoyer un email.





Avatar
Buddy
Salut

Les ralentissements proviennent probablement de la politque de verrouillage des enregistrements et
du niveau de sécurité de la base.
Il faut savoir que lorsque tu ouvres une connexion avec un fichier mdb distant, cette connexion est
peristente et le moteur jet en interne n'est pas très performant entre le suivi de la sécurité des
accès (gestion des droits des utilisateurs) et la mise à disposition des données.

Les performances se dégradent très vite dès qu'un utilisateur ouvre un enregistrement en
modification avec verrouillage de celui-ci.
Il faudrait aussi s'assurer que toutes les requêtes d'extraction soient en mode Snapshot et pas
dynamique. Le mode dynamique garde un lien avec la source. Snapshot se rapporte plus à une vue.
En gros si tu veux conserver cette architecture et améliorer un peu tes temps de réponse, tous tes
objets doivent être indépendants, rien ne doit être dynamique et tu alimentes tes contrôles à la
mano à l'ouverture des formualires.

A cet état il faut en plus tenir compte de la vitesse du réseau et des différentes priorités des
connexions.

Ouala
Bye
Buddy




Salut Buddy,

Merci pour tes réponses, ça me satisfait !
Par contre, sur un point je ne trouve pas ça très clair, voir plus bas :


"Buddy" a écrit dans le message de
news:
Bonjour à tous,
Salut


J'utilise DAO pour ajouter des enregistrements, avec la méthode AddNew, et je les met à jour
avec la méthode Edit. Sur ces points, je pense que c'est propre.
J'utiliserai plutôt une requête SQL du genre INSERT INTO ou UPDATE à la place de .AddNew ou

.Edit, le SQL est bien plus performant d'une part et d'autre part si tu passes sur serveur de
type SGBDR là le SQL est obligatoire sinon t'as aucun intérêt à migrer.


Par contre, là où je pense que c'est moins bon, c'est dans la restitution de données. En effet,
par exemple, j'utilise Me.RecordSource = "SELECT .... " pour remplir un état. Et j'ai
l'impression que cela est très pénalisant, dans la mesure où tant que l'état est ouvert, le
recordset est maintenu sur la table. Ce qui fait que ça ralenti énormément si quelqu'un veut
aussi requêter sur cette table. Est ce que je me trompe ?
Non, le problème avec Access, c'est que à chaque fois que tu extraits des données d'une base

distante, le moteur Jet te renvoie la totalité des données et ensuite il exécute en local tes
sélections. A l'inverse avec un serveur de type SGDBR en ADO, le serveur te renvoie juste ce
dont tu as besoin en gros ne passe sur le réseau que le résultat de ton SELECT. Je te fais pas
dire l'écart des performances.


Voila : tu dis que le problème vient du fait que Jet doit récupérer
l'intégralité de la table en local pour traiter la requête, sur ce point ok.
Mais ce n'était pas mon problème de base. Moi je disais que si quelqu'un
avait par exemple un état d'ouvert à l'écran (depuis 5 minutes par exemple),
les accès pour un autre utlissateur sur un autre poste, se trouvaient très
ralentis. En cela je ne vois pas en quoi le fait que l'intégralité de la
table soit rappatriée en local mette plus de temps si quelqu'un a déjà
accédé à la table (et par là j'entend que le transfert de l'intégralité de
la table a été terminé depuis plusieurs minutes) ou pas.
Peut être pour illustrer mieux ma question : tu sais quand quelqu'un ouvre
un état dont les données sont puisées sur une base 'serveur', il y a un
fichier .ldb qui se créé. Et bien quand l'état est fermé par le client, le
fichier .ldb est supprimé. Je sais à quoi correpond le fichier .ldb, mais
j'avais donc l'impression que de maintenir l'état ouvert 'bloquait' en qq
sorte des accès concurrents ou tout du moins les ralentissait fortement, en
tout cas c'est ce que j'ai constaté... et donc le fait que les données
soient rappatriées en local n'explique pas ces ralentissements.



J'ai donc par un moment pensé à rappatrier d'abord localement les données sur la base locale,
puis requêter sur ces tables locales. Mais ça me paraît plus lourd à gérer ... Cependant si
c'est la solution ...
Trop fastidieux et bonjour l'usine à gaz ! Et puis si tu rapatrie tes données en local, comment

tu vas suivre les mises à jour faites par les autres utilisateurs ?


De même, dans mes formulaires, pour les zones de liste, je les alimente en données avec une
chaîne SQL. Et là aussi, même effet, ça "maintient" un recordset sur la table tant que le
formulaire est ouvert ...
Si tu passe sur SGBDR, tes temps de réponse seront incomparables.


En somme :
Si je reste avec mon architecture (Access en client serveur + DAO), quelle est la bonne méthode
à utliser afin de na pas bloquer des recordsets sur les tables ?
Mais tu ne vas pas rester avec ton architecture, rêves pas. Tu n'auras jamais des temps de

réponse acceptables avec Access serveur.


Ais je intérêt à passer en ADO, avec un serveur MSDE par exemple ?
A ton avis ??? :')


Et pouvez vous me confirmer que :
- DAO permet l'accès aux données seulement si on est en Access côté "serveur"
DAO est en fin de règne, à ce rythme il ne va plus permettre grand chose


- ADO n'a d'intérêt que si on utlise un SGBDR type SQL Server, Sybase,MySQL, Oracle ...
En général la règle est simple : DAO quand c'est access et ADO pour tout le reste.


- En ADO, vaut il mieux passer par un DSN ODBC, et attacher les tables dans la base client, ou
bien écrire les chaînes de connexion "à la main" sans DSN ODBC
Il faudra créer un DSN système (accessible par tous les utilisateurs de l'ordinateur) sur chaque

machine qui pointeras vers ton serveur et ta base.
La gestion d'une connexion basée sur un DSN c'est plus simple.
L'idéal c'est une connexion dite DSN-Less avec une chaine de connexion propre au serveur que tu
choisiras. Il en existe des tas.

- Un DSN est il nécessairement une connexion ODBC ?
Oui.


D'avance un grand merci ...

Laurent



--
Ouala
Bye
Buddy

PS : retirer 123 pour m'envoyer un email.




--
Ouala
Bye
Buddy

PS : retirer 123 pour m'envoyer un email.