DAO vs. ADO : l'éternelle question!

Voici ma petite histoire, pour vous mettre en contexte. Vous pouvez sauter à la question du bas si ma biographie ne vous intéresse pas! ;)

Quel objet est le meilleur? Je ne suis pas le premier à me poser cette question, et je ne serai certainement pas le dernier! Comme tous les débutants, j'ai commencé avec DAO. Déjà là, je trouvais que la marche entre les formulaires liés à une table ou une requête et ceux liés à un Recordset était très haute! J'ai eu quelques problèmes avec DAO, mais, après coup, je réalise que les problèmes venaient davantage de moi que de l'objet!

J'ai par la suite découvert ADO. À première vue, ce que les gens semblaient dire c'est que c'était plus "souple, stable et rapide" que DAO. J'ai donc changé tous les objets DAO de mon programme pour des objets ADODB. Le code est plus long et plus complexe, mais, si je devais gagner en performance, ça valait le coup!

Au fur et à mesure que j'améliorais mes compétences et que mon programme augmentait en complexité, j'ai commencé à lier certains formulaires entièrement sur des Recordsets. J'ai surmonté certains problèmes, mais il y en a encore que j'ai peine à résoudre de façon "propre". Avant d'aller plus loin dans la résolution de mes problèmes, je voulais faire un choix (quasi) définitif: ADO ou DAO? Si cet article que j'ai trouvé, qui remonte à 2006, dit vrai, je crois que je serais mieux avec DAO. Par contre, je voulais avoir l'opinion de VRAIS utilisateurs et pas seulement des avantages/désavantages théoriques. Ce qui m'amène à ma vraie question:

Qu'est-ce que VOUS utilisez comme objet de manipulation de données dans vos projets?

Voici les détails de mon projet à moi:

- Access 2002 sous Windows XP (environnement gouvernemental, je n'ai pas le choix!)
- "Front-end" Access utilisé par des utilisateurs sur 3 serveurs différents qui se connectent à une base Access sur un de ces serveurs. Certaines tables sont locales, d'autres sont liées à la base du serveur, d'où mon besoin de gérer 2 connexions différentes.
- La base pourrait éventuellement être transférée sur un serveur SQL Server, mais rien n'est décidé.
- Mon besoin principal est d'augmenter la rapidité pour les usagers qui se trouvent sur les 2 autres serveurs.

Vous pouvez m'aider simplement en votant, mais vous pouvez aussi commenter votre réponse!

Bonsoir,

J'utilise de préférence DAO pour manipuler des données ou des objets Access.
Plus facile à utiliser, à mon sens, car dédié au moteur de base de données d'Access (Jet).

J'utilise ADO pour ce qui n'est pas Jet (SQL Server, Oracle).

Cordialement.

Salut,
j'ai commencé avec DAO, et j'essaie de basculer progressivement vers ADO.

Bonjour

La cible de DAO c'est le moteur de base de données JET ... sur lequel repose Access. ADO a été conçu pour pallier au manque de RDO (apparu avec VB5.0) et qui était déjà dans une optique Client - Serveur (Remote Data Object).

DAO reste encore aujourd'hui le meilleur choix pour une base de données Full Access (et non un projet adp où ADO est le mieux placé car avant tout destiné pour SQL Server ... sur lequel repose ADP).

Pour preuve que DAO a encore de beaux jours devant lui : il est repris dans la bilbilothèque Access Data Object Library depuis Access 2007 pour traiter les bases de données du moteur ACE (remplaçant de JET). Il intègre en outre les nouveaux champs Pièce Jointes et les champs à valeurs multiples.

Quant à Access 2010, là encore DAO gère très bien les nouveautés puisque par exemple, il est possible de créer en VBA des champs calculés.

;)

Bonjour
J'utilise Dao pour le applis purement Access (car je trouve que c'est plus facile) et Ado pour se connecter à des bases externes (As400 entre autre).

Eh bien! Je vois que DAO est très apprécié! En effet, après avoir changé mes objets de Recordset (encore une fois), je constate en effet que DAO est un peu plus simple et rapide que ADO. Il cause aussi beaucoup moins de problèmes si le code plante ou si on l'interrompt avant d'avoir fermé la connexion!

Malgré tout, je suis content d'avoir pu expérimenter ADO. Ça va me faire une bonne base si jamais j'ai un jour à migrer vers d'autres bases de données.

Bonjour à tous,
je suis surpris de vous entendre dire qu'ado est plus difficile que DAO !!
En fait, c'est pratiquement la même chose question programmation !
De plus ADO fonctionne parfaitement et est trés rapide. Ce sont les recordset qui sont extèmement lent. Mais le execute de la connection ADO est d'une précision hors du commun.
Que ce soit access, SQL server, Oracle ou Sybase, rien de plus facile avec ADO !!

Salut
J'ai vraiment pas de préférence.
J'essaye avec DAO, cela ne marche pas alors j'essaye ADO.
Par exemple, je voulais récupérer un recordset en source d'une zone de liste à plusieurs colonne:
->avec DAO j'ai été obligé de parcourir le recordset pour construire la chaine
->avec ADO on utilise tostring.
@+

Bonjour,

Personnellement je n'ai pas de préférences. J'aurai plutôt tendance à utiliser DAO suite aux migrations successives d'une appli access 97 vers 2010. Pour les composants externes dont la majeure partie sont écrites en VB6 j'utilise ADO suite à des problèmes de communication lorsque le composant est appelé à partir de la commande shellExecute !

JimBoLion

Citation:

---

Envoyé par ainasarn

Mais le execute de la connection ADO est d'une précision hors du commun.
!!

---

Qu'est ce donc que la précision dans ce cas présent ? On pourrait croire que vous sous entendez qu'un ordre DML de modification du client n°2 modifierait de temps en temps le client n°3 avec DAO ... :mouarf:

DAO est plus simple avec Jet car son modèle objet a été conçu pour les objets existants de JET. Une table (Table) est un TableDef, une requête (Query) est un queryDef. Sous ADO, quid des objets Procedure et View avec Access ? L'ouverture des recordset est aussi plus facile puisqu'il n'y a pas besoin de définir la "Location" du curseur et il y a beaucoup moins de pièges à éviter.

De plus, en une seule référence DAO combine à la fois : la structure de la base, ses données et la gestion des utilisateurs, quand sous ADO, il est nécessaire de manipuler 3 références différentes.

Citation:

---

Ce sont les recordset qui sont extèmement lent

---

Sur une application liée à une base de données, la lecture la recherche et le tri des données représente une part majoritaire des temps d'utilisation. Combien d'enregistrements lus pour un seul de modifier ? Utiliser des recordset lent est bien plus que dommageable.

Citation:

---

Par exemple, je voulais récupérer un recordset en source d'une zone de liste à plusieurs colonne:

---

Pourquoi ne pas affecter directement le recordset DAO à la zone de liste ?

Le modèle DAO est peut-être agé mais il prend seul en charge les nouveautés apportés par 2007 et ultérieurs.

Salut
Comment?

Citation:

---

Envoyé par Tofalu

Pourquoi ne pas affecter directement le recordset DAO à la zone de liste ?

---

Merci d'avance.
@+

Code:

---

1 2 3 4 5 6

Dim oDb As DAO.Database Dim oRst As DAO.Recordset Set oDb = CurrentDb Set oRst = oDb.OpenRecordset("MaTable", dbOpenDynaset)   Set Liste0.Recordset = oRst

---

Salut
Merci de la réponse
je vois dans beaucoup de codes...

Code:

---

1 2 3

Dim oDb As DAO.Database Set oDb = CurrentDb Set XXX = oDb.YYY

---

Pourquoi ne pas faire directement...

Code:

---

Set XXX = CurrentDb.YYY

---

@+

Comme expliqué ici :

http://warin.developpez.com/access/d...tie_3#L3.3.1.1

Citation:

---

Cette méthode fournie par l'objet Access.Application retourne une variable de type Database correspondant à la base de données actuellement ouverte dans le logiciel Microsoft Access. La méthode Currentdb crée une nouvelle instance de la base de données à chaque appel. Aussi, vous devez récupérer son résultat dans une variable objet de type Database pour pouvoir l'exploiter.

---

Lorsqu'il y a qu'un seul appel, cela ne pose pas de problème mais c'est une bonne habitude à prendre ;)