MDE, FrontEnd/BackEnd

[TheB]

Hi there,

I am currently in process of building Access database for a friends business. I was hoping to create an MDE file for him to use as I wanted it to be executed via a icon on his desktop rahter than going into Access. I thought I could achieve this with an MDE executable file. However as I dig deeper into this project I see that once an MDE file is created it is very difficult to modify the application. I am not sure he would like this as there bound to be changes in the future. I am very new to access and I was wondering if you recommend the front end/back end setup. If so could you explain how to set this up and establish links between the two? Or if you could lead me to some good documentation to read on how to do it I would appreciate it.

Thanks in advance.

...TheB

P.S. btw, great forum. I'm glad I found it.

 

[chewy]

just make a backup copy of the database before you make the mde file.

 

[Pat Hartman]

.mdb's are semi-compiled databases with all the source objects removed. Once an .mdb is made, you can no longer make changes to forms/reports/modules. Therefore, if you need to make any future modifications, you will need to go back to the original db, make the changes, and regenerate the .mde. So it is CRITICAL to never loose the original db. If you do, you are simply SOL. There is no way out. If your friend will be taking over maintenance of the db, he MUST have the original db.

Splitting the db into a fe and be is only recommended if:
1. multiple users will be using the db
2. the db objects will be maintained by someone other than the person who is doing the data entry.

For a single user application stored on a local hard drive where the user will be making his own object modifications, splitting the db is NOT necessary.

The easiest way to split the db if you decide to do so, is to choose the menu option to do it for you. Once you do this, you will need to become familiar with how to use the linked table manager. When you move the fe and be to your client's PC, if the drive/directory path are not IDENTICAL to the setup on your PC, the tables will need to be relinked via the linked table manager after they are moved to the new PC.

 

[TheB]

Pat and chewy,

Thanks for your help. WRT to your reply Pat. If I had to make a modification to the database what would happen to all the existing data with the new version?

Or would I just copy the new MDE file to users PC?

I am assuming the MDB file contains all the data and the MDE contains the forms/reports etc?

Thanks again.


...TheB

 

[Pat Hartman]

If you use the split db model, the fe is simply replaced with a new version and the data in the be is not affected. Of course the process gets more complicated if you need to make table design changes.

When you're working with the split db model, it is important to keep track of which db be the fe you are changing is linked to. So keep a copy of the be on your local drive for testing purposes. Then when you need to change the fe, copy it to your PC and relink the tables to your test be. Make your changes, then relink back to the production be before moving in your new copy. You of course need to make sure that everyone is out of the db when you are installing the new version.

 

[TheB]

Pat,

I am assuming I am not going with the split example when I asked my last question. From your note it seems that i can modify the Access database and regenerate the MDE. what would I have to re-install on the users PC to complete the update? The MDB & MDE. Or could I just copy over the MDE and it would work fine?

Thanks again.

 

[Pat Hartman]

If YOU are going to be making changes to a database that SOMEONE ELSE is using for data entery, I strongly suggest that you use the split db model. If the database is split, you can make modifications to the fe db and copy it to the user's PC without affecting any data that exists in the be db. The same process applies if you first make an .mde from your fe db. If the objects and tables are both in a SINGLE db, then you can't just replace the db on the client's machine. You also need to address the issue of getting his current data into the new copy of the db.