[Newbie Access] DAO of ADO*

[bluesbrother]

Beste mensen,
Ik ben nu een tijdje bezig in Access en ik heb onlangs weer een boek gekocht:

( Programmeren in Access 2003 ISBN: 9039523290)

En ook daar weer lees ik veel over ADO en niks over DAO.

Ik ben een beetje confused omdat ik weer op andere fora / forums (?)
lees dat ADO oud en versleten is en dan je alles met DAO moet doen.
Dan heb je nog QueryDefs en zo nog wat van die kreten.
Ik wil me graag richten op 1 of twee van deze technieken en die goed bestuderen,
Wat ik nu wil weten is wat gebruik je en wat niet.
En wat gebruik je waarvoor.

Ik heb gezocht op GoT en geggoogled maar ik mis een beetje een eenduidig antwoord.
Wat zijn jullie bevindingen?

BB

[Lustucru]

Data Access Object (DAO) is het oude beestje van de twee. Het voordeel (imho) van DAO is dat het zeer nauw samen kan werken met de native jet-engine, of te wel optimaal gebruik maakt van de nukken en eigenaardigheden van access databases. Kom je daarbuiten of wil je op een gegeven moment meer dan Access-desktop databases maken dan loop je vast.

ActievX Data Object (ADO) is een generieke schil rondom (bijna) willekeurig welke dataprovider. Flexibeler, i.h.a. krachtiger -met name bij client-server toepassingen)- maar in het specifieke geval van mdb bestanden beperkter in de mogelijkheden. DAO kan ik zowat dromen, dus als ik snel even iets moet doen grijp ik naar DAO, maar noway dat ik het ging leren als ik nu zou moeten beginnen.

offtopic:
even je titel ontcapt. Al die hoofdletters staan zo schreeuwerig

[ Voor 8% gewijzigd door Lustucru op 22-09-2005 20:14 ]

[bluesbrother]

Hee bedankt Niesje,
Duidelijk antwoord.
Maar dan nog een vraagje: ik zie ook dingen als querydefs, en zo zag ik wel meer kreten die gebruikt werden om contact te krijgen met een database.
Wat ik nu gebruik zijn dao recordsets voor select's en docmd.runquery en dan gewoon SQL.
Is dat goed of kan dat anders en beter?

[bluesbrother]

Sorry dat ik dit weer omhoog kick maar al lezende wordt het me alleen maar verwarender.
Hier staat het e.a. over Jet Databases in combinatie met ADODB.
Het zal wel aan mij liggen maar ik zie de bomen door het bos niet meer.
Ik hoef niet een complete uitleg maar ik snap de verhoudingen niet.
Het boek is daar ook niet duidelijk over.
Ik lees hier verder het e.a. over OLE DB Provider en nu ben ik de draad helemaal kwijt.
Als ik een poging doe om het zelf samen te vatten dan komt het hierop neer:
(aan jullie de vraag om me te vertellen of ik het wel of niet goed begrepen heb)

Er is DAO, die je het beste kan gebruiken als je alleen binnen access databases werkt.
(ook als je die gesplitst hebt?)

Maar ik bergrijp uit het verhaal van Niesje dat ik deze beter kan laten voor wat het is en me op
ADO kan storten. Ik zal voor nu wat simpele databases maken in alleen access, maar dit zal zich al lerende uitbreiden naar samenwerking met Oracle en MS SQL databases. Voor hier op school.
Sync'en met leerling gegevens zal tot de mogelijkheden moeten gaan behoren.

Dus zal ik me gaan storten op ADO.
Dit is een ActiveX component met vele mogelijkheden. Een provider maakt eigenlijk uit waarmee je conctact maakt. Dit kan Oracle zijn, of Excell, of MS SQL enz.
De provider die je specificeert in:

code:

ADOBDB.Connection

Connection1.open "Provider=Microsoft.Jet.OLEDB.4.0;" & _ 
DataSource="C:\Program Files\Ergens\een database.mdb;"

Maar geldt dit ook voor als je (voorlopig) alleen in access zelf werkt.
Ik wil me nu iets aanleren waar ik in de toekomst ook wat aan heb.
Het vreemde is alleen dat ik veel tegenkom over DAO.
(VTC VBA in Access)

Ik zou graag advies willen in welke richting ik het zoeken moet.

bb

[M. Mulder]

Ik heb 4 jaar geleden ook voor deze vraag gestaan en ik had toen al ervaring met DAO. Zij gaven toen aan dat ADO veroudert was, echter ben ik toch de ADO weg ingeslagen en ik heb er geen moment spijt van. Ik gebruik ADO binnen mijn Visual Basic programma's. ADO biedt veel meer subtielere objecten, zoals texboxen, comboboxen, dropdowboxen, datagrids enz.
De manier van aanroepen via SQL werkt perfect.

Voor mij alleen ADO.

Wat je al aangaf, het is allemaal zeer lastig wat de terminologieen inhouden m.b.t. de relaties. Ik snap dat ook niet allemaal, maar ik heb inmiddels zeer degelijke datbase aplicaties gemaakt op basis van ADO en aansturing via SQL.


Machiel

[Verwijderd]

Ik denk dat zowel Access (en interne DAO) en ADO allebei niet meer erg toekomstbestendig zijn. De volgende generatie is .Net met ADO.Net, wat heel erg verschilt van ADO.

Mbt OLEDB: er zijn twee heel bekende open manieren om via een universele laag databases te benaderen, nl. ODBC en OLEDB. OLEDB is nieuwer en sneller, maar niet multi-platform (alleen windows). Daarnaast zijn er voor databases vaak ook speciale libs die zonder zo'n universele tussenlaag werken. Het voordeel van zo'n tussenlaag is wel dat je minder database specifieke code hebt.

Mbt Access zou ik ADO met OLEDB drivers gebruiken zoals je nu doet.

[bluesbrother]

op Digihans lees ik dit

ADO code is de beste keuze als u niet-Access gegevensbestanden aan een Access programmabestand wilt koppelen. DAO is de beste keuze als u een Access gegevensbestand aan een Access programmabestand wilt koppelen.

[Verwijderd]

Access zelf werkt standaard met DAO ( kijk maar naar de referenties, als je in een codescherm zit ), en dat werkt in access databases erg goed. je KUNT wel ADO gebruiken, maar dan zijn sommige dingen zoals het direct werken met de databasedefinities ( tabledefs, querydefs) een stuk lastiger. ADO heeft hiervoor ook wel functionaliteit ( ADOX, om nog maar eens een afkorting in het topic te storten ), maar die werkt niet optimaal ( toegevoegd tabellen niet zichtbaar in Access, maar wel toegankelijk, en dat soort dingen )

Mijn advies, zo lang je in Access werkt, blijf dan ook lekker bij DAO. Wil je later je database benaderen via andere programmatuur, dan kun je daarin alsnog ADO gaan gebruiken.

[bluesbrother]

Duidelijk antwoord.
Al lijkt me dat DAO ook niet al te moeilijk is om te begrijpen.
ik heb tot nu te gewerkt met :

code:

Public dbase As DAO.Database
Public recset As DAO.Recordset

voor selecties ed.

en

code:

    DoCmd.RunSQL ("UPDATE tbl_tabel SET [kolomnaam]=waarde")

is dit de manier om te werken?
(je hoort/leest) zo veel verschillende manieren.

[Verwijderd]

Er is met dit soort zaken zal je eerst het object model (welke objecten er zijn, welke methodes en properties ze hebben) moeten leren kennen, en pas daarna leer je te begrijpen wat 'best practices' zijn en waarom.

[Verwijderd]

bluesbrother schreef op vrijdag 23 september 2005 @ 15:57:
is dit de manier om te werken?
(je hoort/leest) zo veel verschillende manieren.

Standaard komen "Database" en "Recordset" al uit de DAO library, maar het altijd netjes om het op jouw manier te declareren, vanwege de duidelijkheid.

DoCmd.runsql echter is vrij traag, ik gebruik meestal iets zoals :

Visual Basic:

dim dbs as database
dim rs as recordset

set dbs = currentdb
dbs.execute("UPDATE tbl_tabel SET [kolomnaam]=waarde")

set rs = dbs.openrecordset("Select * from tbl_tabel")

offtopic:
let op, bovenstaande code is uit mijn hoofd ingetypt en kan fouten bevatten

de werkwijze met eerst een referentie naar de database in een variabele te zetten is vooral efficienter wanneer je meerdere Executes achter elkaar wilt doen.

[ Voor 18% gewijzigd door Verwijderd op 23-09-2005 16:05 ]

[bluesbrother]

Kijk dat soort dingetjes dat

code:

docmd.runsql

trager is dan jou oplossing dat kom ik nergens tegen.
Of heb ik verkeerd gezocht. ?
Als jullie een webiste hebben waar ik dat soort kennis tegen kan komen
dan houdt ik me aanbevolen.

Ik zal zelf even beginnen:

http://www.access-programmers.co.uk/

http://home.planet.nl/~digihans/pc_help/access/

http://www.dbforums.com/f84

http://www.fontstuff.com/access/index.htm

[bluesbrother]

Ik ben er een tijdje op zoek naar geweest maar dit gaf mij wel bijna alle antwoorden op mijn vragen.

http://msdn.microsoft.com.../dnacc2k/html/acchap2.asp

en http://msdn.microsoft.com.../dnacc2k/html/acchap7.asp

Misschien dat jullier er ook wat aan hebben.