Results 1 to 6 of 6
  1. #1
    Join Date
    Mar 2004
    Posts
    83

    Unanswered: Practicallity of an MDE?

    MDE seems nice for removing design permissions, but what if a change needs to be made. Exporting from the MDB doesn't work, and importing from the MDE doesnt work. Seems like the DB has to be carved in stone for it to be useful.

    Am I missing an option somewhere?

  2. #2
    Join Date
    Jun 2004
    Location
    Terrapin Nation
    Posts
    205
    Since it only takes 5 seconds to create an MDE file, you just recreate it after you change the .mdb file.

    It is a nice way to get some security in no time at all.

  3. #3
    Join Date
    Mar 2004
    Posts
    83
    Doesn't the actual data the users create/update reside in the MDE though?

  4. #4
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    What sort of structure do you currently have you your db?

    I find that the compiled "applications" are best served as either one-off secure databases that are not shared by anyone, or as a front-end to a common db.

    If you only have one user you're pushing this db out to, it's no big deal to import the current information into your mde.

    If you're supporting multiple users... that could be a headache.

    Anywho, writing import scripts isn't to bad. A little tedious, but not bad.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  5. #5
    Join Date
    Oct 2003
    Posts
    706
    Me, I don't use 'em. Too much trouble. And no 'real' security anyway. It just becomes a pain.

    Y'know, MS-Access security, like that of all file-oriented databases, is really designed to go (Click!) instead of ka-blewie! when the user asks "Shoot me in the foot." It's not really designed for protecting either your data or your secrets, and the features that purport to do so are, in my long experience, not worth the effort. It goes beyond the system's architectural nature, despite the promises of the marketing department, and creates considerable maintenance issues that are best avoided.
    ChimneySweep(R): fast, automatic
    table repair at a click of the
    mouse! http://www.sundialservices.com

  6. #6
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    Doesn't the actual data the users create/update reside in the MDE though?
    ...that's up to you!

    ignoring the security stuff for the moment, the simplest way to handle the data thing is to split the data backend from the user frontend and then link the backend .MDB (...there is nothing to "compile") data tables to the .MDE frontend. it's the only practical way of providing users with front end updates, and it takes you 2% of the way to the next step of having your data on an SQL-aware server. you can even share the .MDB on a file server with reasonable results if you have a modest database, few users and an uncluttered LAN

    try A's database splitter wizard on a copy of your .MDB as a first-pass effort at split front/back... if your table schema is not too messy it does a reasonable job.

    izy
    currently using SS 2008R2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •