05. maj 2002 - 16:39Der er
21 kommentarer og 2 løsninger
MDE contra MDB
Er meget i tvivl om jeg skal oprette en MDE-fil når jeg er HELT færdig med at udvikle min database eller ej....
Ved godt at ved at oprette en MDE beskytter jeg bl.a. kode, forms, dB kommer til at fylde mindre osv.
MEN jeg hvad så hvis (læs når) bruger kommer i tanke om at der skal ændres, tilføjes osv i dB ??
Man kan jo selvfølgelig importere tabellerne over i en ny dB, men ikke forms, rapporter mv. Det betyder jo en del ekstra arbejde. Er også OK hvis der ved at oprette en MDE er flere fordele end bagdele :)
Har overvejet at jeg kan vælge at aflevere en MDB hvor jeg har slået diverse funktioner fra i Funktioner/Start.
Hej, i mde kan du eks. ikke rette en rapport til, da al kode bliver fjernede, men du er også fri for folk selv retter i den, og siger det du lavede ikke duer. Laver du en mde så lav en bakop ?. En god ting til mdeer er i delte databaser, hvor du har data i en, og styringen i en anden, du kan så altid komme med opdateringer, uden hensyn til indtastede data. Vh Henrik
Du kan IKKE importere forms, rapporter og moduler fra en .MDE.
Det man altid skal gøre er at gemme den originale .MDB således at man har mulighed for at lave ændringer senere. (når man laver en .MDE så beholder man jo .MDB'en og laver blot en ny fil: .MDE'en)
Man distribuere kun .MDE'en til kunden/brugerne, således at de ikke kan rette i designet. Endvidere kører en .MDE 5-10 % hurtigere end end .MDB, da .MDE'en er kompileret og ikke indeholder al kildekode.
Når man har færdigudviklet sin dB (MDB) kan man vælge at oprette en MDE fil som så distribueres til bruger - større sikkerhed mod pilfingre :)
Hvis du har oprettet en MDE beskyttes alle dine kode moduler incl forms, rapporter m.v
Det betyder så at bruger bl.a. ikke kan rette, slette eller tilføje i f.eks tabeller, queryes, ændre i din kode m.m.
Det der er problemet, er at når du har oprettet en MDE kan du ikke længere rette i den - (den der udleveres til bruger)
Fungerer sådan at du ud fra din MDB vælger at oprette en MDE. Access opretter så en ny dB ex Mindatabase.MDE - så du nu har 2. En med efternavnet MDE og en med MDB
Er godt med på at det er en EMINENT god ide at gemme en kopi af MDB så man altid kan gå tilbage :)
Det jeg mere tænker på er om jeg spænder ben for mig selv ved at aflevere en sådan....
Tænker her på når der skal tilføjes/ændres i design - næhh gør der vel egentlig ikke - kan jo bare vælge at oprette ny dB importere alle eksisterende tabeller og querys frm MDE og så importere kode, forms, rapporter osv fra MDB - eller hur :-)
Besværligt... - mener faktisk ikke jeg har andre muligheder da dB bliver placeret på server som jeg ikke har adgang til. Så ved ændringer er der ikke rigtig andre muligheder end at jeg får tilsendt MDE og så foretager ændringer derfra.. Kan jo sagtens foretage ændringer i den oprindelige MDB, men alle de records som bruger så har tilføjet er jo ikke med....
Ville være betydeligt lettere hvis den var placeret på en af de servere hvor jeg er ansat - og har admin-rettigheder, men det er den ikke :)
Er bl.a. der for jeg har oprettet spørgsmålet. Ønsker IKKE at der kan pilles i kode, forms, tabeller osv. Så det mest sikre vil vel være at oprette en MDE
jamen, har du ikke splittet databasen op i en Frontend og Backend? Således at tabeller ligger i én database og alt andet ligger i en anden?
Det er klart den mest hensigtsmæssige løsning, da man netop ellers har problemer med at opdatere applikationen. Endvidere er systemet meget mere udsat for beskadigelser som følge af at flere brugere har den samme fil åben (hvis én bruger ikke lukker korrekt ned, så er databasen beskadiget - og i værste fald kan den ikke repareres) Hvis man splitter op i forntend og backend er systemet sikret mod dette (især hvis hver bruger kan få sin egen lokale frontend)
>thomas nej har ikke splittet op i back- og frontend da dB kun skulle have været en "mindre sag". Men den har undervejs fået vokseværk, så det er måske det jeg skal gøre i stedet for.
Sidder i skrivende stund efter mange timers arbejde og går ud fra at alle ved hvordan dB er opbygget - lol
Kunne heller ikke få det til at hænge sammen med at det ikke var nødvendigt at importere :)
ok - men hvis jeg nu splitter op i front- og backend er det jo muligt at rette i tabel-/kode-delen - lidt noget skod - ønsker jeg ikke skal være muligt.
Kan selvfølgelig beskytte med password men er det nok....
Hi Susanne> If you do decide to split your dB up into a back end and a front end, then there is as you may well know already, a wizard for doing this. Otherwise I agree on Thomas' suggestions :o)
Der er normalt ingen problemer med at splitte databasen op i 2 (ud over at man skal huske at sammenkæde, hvis man flytter databaserne)
Der er dog 2 punkter, som kan give problemer og som man skal være opmærksom på: 1) Hvis man bruger Recordsets af typen Table (dbopentable) og tilhørende .Seek-funktion, så skal man skrive koden om, da .Seek ikke virker på sammenkædet tabeller (det er dog relativt nemt at løse problemet)
2) Hvis man f.eks. har brevfletning og dokumentet peger på en tabel i .mdb'en som datakilde, så skal man enten lade backenden hedde det samme som den oprindelige fil. Eller også skal man ændre datakilden i Word-dokumentet. Hvis datakilden er en forespørgsel, skal den pege på frontenden.
Ud over disse 2 problemer, så har jeg ikke oplevet nogle problemer - tværtimod.
Mht.. til vedligehold af tabelkæder er der et kanon eksempel i eksembeldatabasen ordes.mdb (ihvertfald i 97 udgaven). Noget med at tjekke om backenden findes, ellers popper en 'åben fil' dialogboks op, så brugeren kan opdatere kæderne.
har desværre ikke kunnet finde den db du referer til..
Takker for de gode indlæg :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
