backup igen.

hvad er der i vejen med en alm. copy/xcopy?
Da alle data ligger i én fil, er dette jo simpelt og effektivt.
Problemet kan være at restore enkelte data, hvis man ikke ønsker at restore alle data. Er det dette, som er problemet?

overhovedet ikke... det er kun til backup formål! hvis de skal restores på et tidspunkt, er der en helt anden procedure...
hvad mener du med en alm. copy/xcopy? bare at kopiere filen fra a -> b?!

hvis det er det du mener, er det det jeg gør i min bat fil. jeg lukker databasen, kopiere til destinationen, og åbner db'en igen...

Er databasen ikke splittet op i en frontend og backend?
Det er jo således kun backenden, som behøver at blive kopieret dagligt. Dette kan som oftest gøres uden at brugerene behøver at 'hoppe af'.

det har du ret i, men pt bliver der lavet mange ændringer i frontend'en så den skal sgu med også...
vad mener du med en alm. copy/xcopy?

Ja, ligesom du formentlig gør i din .bat-fil:
Du har formtlig bare en
Copy C:\Databaser\DinDatabase.mdb X:\Backup

(XCopy gør det samme, men den overskriver og opretter bare automatisk mapper og filer)

der er ikke en funktion i access der komprimere, og derefter skriver db'en til en destination? jeg ville gerne undgå den her dos-ting...

Hej, jeg har en domo af det, men ordren er:
DoCmd.TransferDatabase acImport, "Microsoft Access", "Bakop.mdb", acTable, "TblNavne", "C:\dokumenter", False
    Vh Henrik13

Ferdinand, ellers prøv at kigge på denne funktion: http://www.mvps.org/access/modules/mdl0045.htm

jaaa, den har jeg nu set, men jeg ønsker nu bare en lidt mere automatiseret version, men jeg kan måske pille lidt ud af den...?! vender tilbage senere...

Og fordelen ved xcopy er at den den kun copierer filer, der er ændret.
Dvs man for en mappe kan nøjes med at skrive *.*, hvorefter kun ændrede filer kopieres.
Endvidere ....copy og alle de andre kommandodolinje-værktøjer er ikke kun "en dosting". De findes også som ægte Windows-proprammer i NT4.
Nogle at de gamle dosprogrammer er uændrede, men mange er udvidet til NT.

Der findes måder hvor på man kan tage en backup inde fra Access.
Men der er et par 'problemer' i det du ønsker at gøre.
For det første kan du kun tage backup af din backend hvis der ikke er andre der bruger den. Det vil sige at du skal kunne få 'exclusive access' til den.
For det andet kan du ikke tage backup af din frontend fra din frontend! Du kan jo ikke få 'exclusive access' når du selv har den åben allerede.

Jeg har selv lavet en mulighed for at brugerne kan tage backup af backend filer i de løsninger jeg har lavet til professionelt brug (læs - som jeg har fået penge for at lave ) så jeg ved at det kan laves med backend filer, men frontenden er der kun en løsning der rigtigt holder - XCOPY ( eller ROBOCOPY hvis du kører 2000/XP )

thomasjepsen> det er en fin utility du henviser til, men den virker bare ikke på tabeller og har aldrig gjort det. Jeg har skrevet meget sammen med forfatteren og forsøgt at få ham til at lave en ny version, men den er aldrig kommet :-(

hugo, gamle dreng... eftersom du pointere at du har udviklet den til professionelt brug, er det vel ikke noget du vil af med?! :) naturligvis kunne jeg tænke mig en kopi, ellers ender det jo bare med at jeg måtte vende tilbage til min .bat fil?! :)

Hugo->Virker den ikke?? Hmm, det var satans (jeg har da heller ikke selv prøvet den). Men tak for oplysningen ;o)

Jeg har selv lavet flere forskellige løsninger (også til prof. brug :) som enten brugte Docmd.TransferDatabse (som Henrik foreslår) eller blot bruger en Tabeloprettelsesforespørgsel, hvor man angiver stien til en backup-database/tabel.

Dette virker fint, men skal gøres for alle relevante tabeller. Det er dog relativt simpelt at lave en procedure, som gennemløber alle tabeller i databasen og gør det samme for alle.

Problemerne opstår først for alvor, når man skal restore igen ;o)

ferdinand.k>  hvis du nu går ind på mit website under TAXI programmer og downloader den demo der er der. Installerer den og lige venter på at jeg sender dig en opdateret licensfil, så kan du se hvordan jeg har lavet det.
Hvis det er sådan noget du er på jagt efter, må vi jo se om jeg kan pille det ud og sende det til dig på en måde.

thomasjepsen> du har fuldstændig ret i din udtalelse om at det er ved restore at problemerne opstår. Der er jo ingen transactionslog man kan rulle på! På 'min' SQL produktionsdatabase på arbejde tager jeg backup af transactionsloggen hver time, så det er til at komme et step tilbage skulle det blive aktuelt(hvad det 'knock on wood' forhåbentligt aldrig bliver)

jeg takker mange gange for jeres hjælp til dette, men jeg har sgu fundet på noget smartere... til dem af jer der skulle være interesseret, prøv at kigge nærmere på et komponent fra http://www.xceedsoft.com/products/BkpLib/ Det er sgu smart... men i skal da have point'ene alligevel... :)