Konvertering fra 97 til 2000

Hej Knor

Har du prøvet at komprimere din database?

Mvh

LKP

\'2000 er lidt mere krævende hvad angår systemressourcer. Så hvis du ikke har så meget RAM eller så meget ledig plads på C-drevet, så kan det godt sløve lidt ned.

Hvis det er en fler-bruger applikation, hvor flere brugere har den samme .mdb-fil åben, går det også langsommere i Access 2000. Afhjælp dette ved at lade hver bruger have en lokalversion på harddisken og en backend på serveren.

Hvis det ikke er nogle af disse problemer, så er jeg blank...

/Thomas

Jeg har prøvet at komprimere filen og arbejder på en meget hurtig maskine. Så jeg kan ikke rigtigt bruge jeres svar, men tak alligevel.

Kan det evt. have noget at gøre med, at jeg har programmeret lidt VBA halløj, der ikke længere virker? Er der nogen der har erfaring med VBA og konvertering til 2000?

Hej Knor

Har du brugt DAO i din Access 97 version?

Access 2000 er optimeret til ADO, og du bør defor benytte denne teknologi hvis du flytter din database til Access 2000.

Mvh
LKP

DAO og ADO er sort snak for mig. Hvordan ved jeg hvilken teknologi jeg anvender?

Access kan generelt ikke lide død kode. Fjern al overflødig kode - og check, at du ikke har funktioner eller sub\'er med samme navn (kompiler!).

Til LKP og andre interesserede:
Rent faktisk er Access 2000 IKKE optimeret til at køre ADO, med mindre at man arbejder på eksterne datakilder. Dvs primært ODBC eller i et Access Project.
Sålænge du arbejder i rent access-miljø, så er DAO stadig hurtigst, da det er en mere simpel teknik.
Access nåede aldrig at blive 100% ADO-orienteret, så internt arbejder Access med DAO på forms og rapporter m.m. (jvf Access Developers Handbook)

Bare til orientering...

/Thomas

Knor, du kan se hvilke(n) teknikker du benytter ved at åbne menuen Tools->References (fra kode-editoren)

Her får du en oversigt over benyttede libraries. Du skulle således gerne have en \"Microsoft DAO 3.x Object Library\".

Hvis der er en afkrydset reference, hvor der står noget med \"MISSING:...\", så er der en fejl og den reference skal fjernes eller rettes til det rigige (hvad det end måtte være)

Jeg tror nu ikke at dit problem har noget med DAO kontra ADO at gøre, men hvem ved med Microsofts forunderlige verden ;-)

Hej Thomas

Jeg er enig med dig i, at ADO ikke er 100% implementeret i Access 2000 og at DAO bruges når du bygger en form/rapport på et recordset, men jeg kan ikke umiddelbart finde belæg for dine andre synspunkter herunder.:
Hvor finder du at DAO er hurtigere?
Hvor finder du at Acces ikke er optimeret til ADO?.

Jvf.: Access Developers Handbook Vol 1 s. 212:
  \"Previous versions of Access used a different library, named Data Access Objects (DAO), for programmatic access to data. DAO began life as an interface til the Jet database engine in Access 1 and grew in size and complexity through Access 97. Although DAO is still present in Access 2000, it\'s no longer the preffered method for retrieving data...\"

Og s. 215
  \"... Access 2000 allows you to create two different kinds of applications, natively. You can create and MDB file, or you can choose to create and ADP file(An Access Data Project): in both cases, for new applications, Access uses OLE DB (through ActiveX Data Objects, or ADO) to retrieve data. ...\"

Dette er ikke for at starte en større diskussion, og du må meget gerne komme med argumenter for det modsatte, og måske overbevise mig.

Hvis du har benyttet DAO (brug thomas\' måde til at undersøge det på), og du i din nye database har en reference til ADO, bør du prefikse dine objekter med den korrekte teknologi, hvilket sparer lidt tid, da du explicit har angivet hvilket bibliotek dit recordset, connenction mv. kommer fra.

Eksempelvis deklareres et ADO recordset med:

Dim rstTest as ADODB.Recordset
Set rstTest = new ADODV.Recordset

Håber at du kan bruge ovenstående, ellers skriv igen.

Med venlig hilsen

LKP

Hey LKP igen,

Ja, jeg indrømmer at jeg var lidt for hurtig med kildeangivelsen. Jeg anser som regel Access Developers Handbook (ADH) for \'biblen\' og jeg mener da også at principielt har den ret i at ADO er den foretrukne model. Men mest fordi, det er den fremtidige model og den mest avancerede. Ikke fordi det er den hurtigste på nuværende tidspunkt.

Den bog, som jeg burde have refereret til istedet, kan jeg ikke give titlen på lige nu, da den står på mit arbejde (hvor jeg ikke er de næste par dage). Så kan der gå lidt tid, før jeg kan give dig den korrekte titel (og evt sidenr).

ADH fremtidssikrer bare deres bog ved at udelukke DAO allerede nu - og man har svært ved at modargumentere dem.
Men hvis man ved hvad man gør og hvorfor man gør det, så vil jeg stadig påstå, at man opnår den bedste performance ved at bruge DAO i den givne situation.
Noget helt andet er, at jeg selv til enhver tid vil benytte ADO - ikke mindst fordi at systemet dermed er mere kompatibelt med fremtidige versioner af Access.

Jeg vender tilbage med titlen senere!

Imens kan du jo kommentere lidt :-)
Vi kunne evt fortsætte diskussionen via mail istedet, så vi ikke genere den stakkels Knor\'s spørgsmål.
(tj@makeiteasy.dk)

/Thomas