Hello Folks
Jag har slängt ut lite "vedträ" om ADO
Det har aldrig tagit sig.

Behöver man kunna ADO om man håller sig till Access
Nej blir mitt svar DAO 360 är optimalt till Access

mvh
Slänger Sven ur sig

Hej Sven.

Det är möjligt att du har rätt...

Men, jag lärde mej aldrig DAO så jag vet inte. När jag började programmera (2 år sen) så sa folk till mej att DAO är en föråldrad metod för dataåtkomst.

Jag gillar ADO:s objekt för att de är så lätta och flexibla att använda.

Fast nu är det bara ADO.NET som gäller... (för mej)

//fredda

> <b>Behöver man kunna ADO om man håller sig till Access</b>

Jag kan inte skillnaderna mellan ADO och DAO. Men varför ska man låsa en lösning till enbart ett databas-system?

Flixibilitet är bra, låsning är dåligt!

Microsoft har en trevlig översiktsbild på hur de olika delarna hänger ihop!

A Comparison of the ADO and DAO/RDO Architectures
<URL:http://www.microsoft.com/data/archb.htm>

> <b>Nej blir mitt svar DAO 360 är optimalt till Access</b>

Vilket inte säger ett enda dugg!

Motivera istället varför DAO 360 är bättre än ADO för Access.

Hej
>Motivera istället varför DAO 360 är bättre än ADO för Access.
> Nej blir mitt svar DAO 360 är optimalt till Access : skrev Jag
"Vilket inte säger ett enda dugg!" > Skrev Rickard
Ordet optimalt finns kanske inte i din ordlista ?

Får känslan av att man skjuter mygg med kanon om
man kör ADO mot enbart en AccessDatabas.

Dvs man lägger in kapaciteter som aldrig används
Slöseri med minnesresurser processorkraft.
DAO är skräddarsytt och efter många versioners förbättring
den optimala motorn till en AccessDatabas.

Ser här flera ggr att de simplaste DataBaslösningar så blir
alla svar struliga ADO lösningar. "Overkill"

Skulle vara mycket intressant att se några Benchmarks på DAO vs ADO.

tycker jag fortfarande
Sven

Håller med SvenPon att DAO för optimal för access. Har bättre find och filtrerings metod på recordseten. Man kan requery ett recordset med en querydef. Man kan desutom accessa och redigera datastruktur.

Men om man valt DAO. Är det ju inte kul när man ska konvertera till ADO. Dessutom måste man sätta sig in i och lära sig DAO's objektstruktur. Kan var mer jobb än vad det är värt.

>>Ser här flera ggr att de simplaste DataBaslösningar så blir
alla svar struliga ADO lösningar. "Overkill"

Håller med. Man kan göra det krångligt för sig oxå...

Det handlar om okunskap. Det finns många genvägar att ta om man bara vet om dem...

Ta nu inte detta som om jag är bäst på ADO...


//fredda

>>>Ser här flera ggr att de simplaste DataBaslösningar så blir
>alla svar struliga ADO lösningar. "Overkill"

>Håller med. Man kan göra det krångligt för sig oxå...

Jag tolkar detta som om du tycker ADO är krångligare än DAO, skulle du kunna utveckla lite varför du tycker så? Jag tycker det är ganska likvärdigt att arbeta med ADO och DAO, även om det syntaktisk skiljer lite.

/Johan

>Ser här flera ggr att de simplaste DataBaslösningar så blir
>alla svar struliga ADO lösningar. "Overkill"

På vilket sätt blir lösninga som använder ADO "struliga"? För användaren? För programmeraren?

"Undrar" Johan ;)

Hej.

>>Jag tolkar detta som om du tycker ADO är krångligare än DAO, skulle du kunna utveckla lite varför du tycker så?

Jag jämför INTE med DAO i detta fallet. Kan inte göra det för jag har alldeles för lite kunskap om DAO. Läs mitt tidigare inlägg.

Vad jag menar är att det inte behöver vara så svårt med ADO. Läser man på lite vad objekten erbjuder finns det massor av hjälp att få om många problem vi står inför.

//fredda

Aha, då missuppfattade jag dej helt...

/Johan

Hej igen.

JohanD. Skall vara tydligare... :-)

>>På vilket sätt blir lösninga som använder ADO "struliga"?

Ett par exempel finns ju i .Find .Filter .Save

Under min korta tid som programmerare har jag ändå hunnit med att se en del dåliga lösningar som dessa funktioner skulle kunna fixa.

(Öhövligt kanske att svara på en fråga som inte var riktad mot mej. Men jag kunda inte låta bli. Sorry)

//fredda

Hej igen DAO DAO som dansken säger

Jag slängde in detta vedträ för att få en motivation
att lära mig ADO. Jag har användt DAO sedan Access
barndom ,det tar emot att övergå till något som man tycker
är avd onödigt vetande. ADO är säkert bra och det riktiga
verktyget, men "Overkill" har aldrig legat för mig.
"Minnessnåla snabba lösningar var ordet" sa Bill just det sa Bull.

ADOjö
Sven

Hej.

Vad jag menar är att det inte behöver vara "overkill" om man gör saker och ting rätt.

Nå, har du fått motivation?

//fredda, som mår illa idag. Hade för roligt igår.

>Ett par exempel finns ju i .Find .Filter .Save

.Save??? Save finns väl bara i ADO eller? Dom andra köper jag :)

Och nej, jag har inget emot DAO om det nu skulle verka så... ;)

/Johan

Hej.

JohanD:
Jag har nog svårt för att göra mej förstådd idag.

Menade återigen ADO. Om folk bara visste att funktionerna fanns skulle man också kodat därefter. Antar jag.

Nu skall jag inget mer skriva förrän jag fått aptiten tillbaka. :-)

//fredda

> <b>"Minnessnåla snabba lösningar var ordet"</b>

Anser du att DAO är mer minnessnålt och snabbare än ADO?

Har du sett någon undersökning på det?

Du kanske skulle vilja göra lite trevliga minnes/snabbets-mätningar mellan DAO och ADO och presentera dessa? Faktiska värden gör det ju enklare att välja den ena eller den andra när man ska bygga sin applikation!

Hejsan

Angående snabbhet mellan DAO och ADO så har minna tester kanske inte vetenskapliga på några plan, men har i minna program använt DAO mot en Access databas i lokala nätverk ansetts snabbare än när jag har testat med ADO.
I dom testerna har ADO visat sig vara ca: 4 sec långsammare än DAO på visa sökningar och då är databasen inte speciellt stor ca:80mb

Men det är väl när man ex, börjar att jobba mot SQL Server/Oracel som ADO kommer på sin rätta plats!!!!.

Det är minna erfarenheter av DAO vs ADO.

Tobbe

> <b>I dom testerna har ADO visat sig vara ca: 4 sec långsammare än DAO på visa sökningar och då är databasen inte speciellt stor ca:80mb</b>

Och hur lång var den totala tiden? 4 sec som ett eget värde säger inte (mig) så mycket.

<b>Men det är väl när man ex, börjar att jobba mot SQL Server/Oracel som ADO kommer på sin rätta plats!!!!.</b>

Skulle man kunna säga att kontentan är; är du 100% säker på att din lösning alltid kommer att köra mot Access så är det DAO som gäller. Och finns det en möjlighet att databasen byts så är det ADO som gäller?

<b>Det är minna erfarenheter av DAO vs ADO.</b>

Intressant, och det tackar jag för!