Pflichtschuldig (wie dort vorgeschlagen) versuche ich DAO herzunehmen (Dim rs As DAO.Recordset), aber ein DAO.Recordset kennt Access gar nicht?! Ja, wo ist denn der Unterschied zwischen ADO und DAO? In den Google Groups findet man dann Erhellendes wie:The DAO and ADO libraries both have a Recordset object, but with different methods, properties, and options.
DAO is the native Access library (what Access itself uses), whereas ADO is a more generic library (now superseded by the vastly different ADO.NET library.)
Aha! Langsam schält sich heraus, dass DAO zuerst da war, und, sofern man sich nur in Access aufhält (also keine verknüpften Oracle Tabellen oder dergleichen verwendet), von allen einstimmig DAO empfohlen wird. Ja, wo ist jetzt das Problem? Mal hier geschaut, Microsoft Access tips: Solving Problems with Library References:Kan D. wrote:My summary would be, there are some things that DAO can do that ADO
> somebody tell me the adv/dis-adv to using ado vs. dao
can't (...) and vice versa (...).
Da, da, stands jetzt! Standardmäßig wird ADO referenziert! So ein Kokolores! Naja, nach einer guten Stunde kann ich jetzt schon ein Recordset öffnen! Wobei man dann noch zusätzlich von anderen Fragestellungen abgelenkt wird:DAO stands for Data Access Objects. It is the object model written specifically for Access, so it's no surprise that it gives the best power and performance for data stored in Access tables.
ADO stands for ActiveX Data Objects. It is a more generic library, designed to handle data from sources other than Access tables, e.g. SQL Server. If you are working on these enterprise databases, you don't need an explanation of ADO here.
In a misguided attempt to move us away from storing data in Access, Microsoft made ADO the default library in Access 2000 and 2002. Consider deselecting ADO, and choosing DAO 3.6 instead.
- dao vs tao - Google Search
TAO vs. DAO? How does that go again?? - tao vs dao
- dao vs hibernate
- DAO vs Entity Beans
- ojeoje...
No comments:
Post a Comment