Results 1 to 6 of 6

Thread: Design View

  1. #1
    Join Date
    Feb 2004
    Location
    Alpine Califormia
    Posts
    1,789

    Unanswered: Design View

    Hi all I have a question, I dont want the users to have the ability to get to the design view of Access, how would I stop that. I know on SQL I can make it so that they cant create but how would I stop them from getting behind the design of a form??

  2. #2
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Make an .MDE...takes the design view off the menus.

    Sam, hth
    Good, fast, cheap...Pick 2.

  3. #3
    Join Date
    Feb 2004
    Location
    Alpine Califormia
    Posts
    1,789
    thank you Scrandall, can you please telll me what an MDE is? Right now Its an ADP. Am I way off or?

  4. #4
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Hmm, don't have much experience with ADPs, but, off the cuff I'd assume an ADE would perform much like an MDE.

    Should be under the tools menu. With an mdb it would be tools/database utilities/Make MDE file.

    Again, I can't say for certain that's what you need to do, but, it'd be my first guess.

    Sam

    Edit:: You should always make a backup of the original file *before* trying to apply major changes to your db. I would also compile and then compact/repair the database before making the ADE file.
    Good, fast, cheap...Pick 2.

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    It should be the same type of process to make an ADE from ADP than it is to make an MDE from an MDB.

    I stopped creating ADP's years ago as you lose the ability to nicely create queries such as you can in an mdb/mde. There more of a disadvantage designing an ADP versus an MDB and the speed payoff of an ADP is not significantly greater than using an MDB with linked tables.

    If speed is an issue (and I'm dealing with millions of records), I'll simply design Unbound forms in an mdb which is essentially the same thing as what an ADP is (BUT I still have the ability to use queries in an mdb.) If it's still chugging using an Unbound form in an mdb (which is rare), I might then use code to tie directly to a stored procedure on the SQL Server (and thus avoid ODBC.) This would be code almost exactly the same as what is used in the ADP (with the exception of some syntax).

    ADP was (in my opinion) more hassle than what it was worth and I saw no evidence that Microsoft was going to keep this technology updated. Plus it took me twice as long developing an ADP versus an MDB using linked tables.

    An MDE (or ADE) is simply a "compiled" version of the MDB or ADP. A compiled version of any code operates faster and doesn't error out to show the code. IF you create an MDE or ADE, make sure you always keep the MDB or ADP in a safe place (ie. a "developers" type folder where only your development staff have access) for making coding updates (to then create a new MDE or ADE) for the users to open.
    Last edited by pkstormy; 09-17-09 at 22:32.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    If the goal is to keep user's from gaining access directly to the tables, you can set the options in MSAccess to "hide" the tables, or you can design a "background" form which opens and maximizes removing the ability to close this form such as in the OnClose event of the "background" form. Since most uses don't know that they can hold the shift key down while opening an MDB or ADP to get behind the scenes, this method typically works good for low security. If it's a high-level security, you may want to consider creating security "groups" on SQL Server itself or specific code in the frontend mdb to disable menus or again, prevent a "background" form from closing. (see some of the examples I've posted in the code-bank. I almost always use the "background" form technique.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

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