Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Working with an .MDE file 1

Status
Not open for further replies.

5tr0ud

Programmer
Aug 9, 2004
29
US
We just split our Access2002 database, and now have an .MDE file on the server. A few questions:
(1) How do we change a Table's structure/property in the .MDE file?
(2) How to maintain\update the .MDE file? I've kept a copy of the original .mdb file (before splitting) and have started to develop a new Query and Form. How do I go about getting this new Query and Form in to the split database? I've read Microsoft's brief explanation and it seems to miss some thing.

Thank you.
 
The .mde (front-end) file should reside on the user's workstation and an .mdb (back-end) file should reside on the server. The .mdb should contain the majority of your tables. The original .mdb file should be used as your development file, where you make front-end (forms, reports,etc) changes, convert to .mde, and redistribute to user's workstations.

--
Mike
 
Thanks Mike555. We have all the files on our network. Is this wrong?
 
When you say "all the files" are you refering to the mdb & mde files?

As long as everyone is satisfied with the arrangement (you with the administration, and your users with the performance) and everything is working fine then there's nothing wrong with your setup.

--
Mike
 
Mike,
We just did this today . . . split the database and put all these files on the network:
Data.mde (1600KB), Data_be.mdb (27,000KB), and Data.mdb (28500KB). The original Data.mdb (before splitting) is in another folder.

If there a better way to do this? We now need to figure out how to get updated or new forms in to the split database.

Thank you so much for your reply.
 
Here's what I would recommend.

1. Split your mdb file into 2 mdb files. One of these mdb files will be your back-end, the other will be your front-end. Your back-end should only contain tables (and queries if you want to store them here). Your back-end SHOULD NOT be an mde file, because most likely you'll need to modify the tables sometime in the future.

2. Place the back-end mdb file on a server in a shared network directory.

3. Now open the mdb file that will act as your front-end. Run the Linked Table Manager to create links from this file to the tables in your back-end database. Convert this file to an MDE file. Place a copy of this MDE file on each user's workstation. Each user will have their own MDE file.

4. After converting to an MDE file, you will still have an mdb file. This will be YOUR development file, which you will use to make changes to forms,reports,macros, and other front-end components.

While this is efficient in some aspects, the only catch is that anytime you need to make a change to the front-end, you'll need to redistribute the updated front-end mde file to all user's workstations.

HTH

--
Mike
 
Mike, thank you for your clear description. Your suggestion is the first option I wanted to try. However, we have many more forms and reports to develop, and would be daily copying the front-end to the users' PC (about 6-10 people). Do you still think this would be the best way to do it? We have been making changes in my unsplit .mdb copy, and then importing the changes to the split .mdb database, and creating a new .mde file (after we have all the users close out of the database.

We will discuss any suggestions you have. Thanks
 
5tr0ud,

As I mentioned above the 'catch' to this arrangement is that you'll always have to redistribute the front-end whenever changes are made. This is the nature of the beast when you're working with a shared Access application.

The setup I've described is the best way to keep your application secure. It is secure because user's only work with the mde. They don't have a chance to mess with your code or accidentally enter design mode and make all types of changes (yes, that's actually happened to me before :)).

If security is not a top issue, you could try another method.... Just simply place the entire mdb (containing tables, forms, code, everything) in a shared network directory and then just give each user a desktop shortcut directly to the mdb. This makes administration easier, but I would strongly recommend against this setup. However, this is another option.

--
Mike
 
Mike, I appreciate your suggestion and personal experience.
What I did do is put a shortcut on everyone's desktop to the .mde file on the network. However, in the same folder is the back-end .mdb file, as well as the other .mdb file that contains the linked tables and other objects (forms, reports etc).

I'll discuss this set-up and security issues with my co-worker tomorrow. Again, thank you.
 
I have just read through your post. I had the same issue and I found the following link in another forum. I've been using it and it works great. Basically everytime the FE is updated you put it up on the network. Everytime a user opens the application with the icon created it will check the shared file for a more recent version (based on the date) If there is a more recent version, it will update it for them.

Auto FE Updater
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top