Split Database and Distribution

[number2]

I am trying to implement and distribute a .mde Access file split into front end (FE) and backend data (BE) files. This will allow me to perform FE updates with the user being able to maintain and back up their data.

I have tried the following and it seems to work:

1) Create the split db in a same named directory which will be added to the users drive on installation (this creates the link to the BE table)

2) Have the user copy and backup their backend file to another directory.

3) Have them install the new frontend and back end.

4) Have the user overwrite the newly installed backend db with their backup version. (while of course not changing the file name or directory location)

I have tested this and it seems to work fine.

Other than counting on the end user to perform this simple task (a mistake in itself!)are there any other pitfalls in doing it this way?

I have looked at some of the "solutions" for relinking to a backend db, and frankly they are very cumbersome and above my head. I need a simple solution which will allow end users to easily update their front end while maintaining their data backend.

Are there any other pit falls to this low tech solution?

 

[thornmastr]

This will do what you want to do. Actually, while you might feel it is a bit complex, if you give it a shot, the results might change your mind.

Good luck.

http://www.mvps.org/access/tables/tbl0009.htm

Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[number2]

Thanks for the help. Will my "low tech solution" work?

Also, how do I make that code example run at start up? I am fiine with implimenting the code, but how to I make it run at startup as stated in the example explaination?

 

[number2]

I am way over my head trying to figure this one out. There are too many hurdles for me to overcome to use that code.

Is it possible to have the user overwrite a newly installed backend db with their backup version of the BE db? (while of course not changing the file name or directory location)

This works in my tests.

As long as the user does not change the location or name of the BE file and their back up. Are there any problems with this?

 

[thornmastr]

How do you intend to test that your tables are properly linked when your program first starts. That is one of the things that routine does do. Access will do everything it can to insure the FE knows the BE.

One thing you might want to consider is when you are ready to distribute your modified FE that it has already been linked to the proper BE. Technically, that is all you should have to do and the new FE will have the correct table attachments.

Where things tend to break down is when you change the location of the BE without linking the FE to the BE. Then you are simply out of luck, which is why that routine I pointed you to will allow your user the ability to point to the correct BE location.

The only way to insure you will not have this problem is when you must change the location of your BE release a new FE that is mapped to the new location and everything will be fine.

HTH.
Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[number2]

I know it is asking a great deal, but do you know how you would impliment that routine you recommended?

I don't know how to run it let alone how to get it to run at db startup. Any help would be most welcome. If I can not come up with a satisfactory solution, I may need to stay with a non-split db.

 

[thornmastr]

This is the routine I use. I do modify it slightly to only fire when I know the directory of the BE has changed. The problem I have in sending you a specific example is this is a part of client software that my clients own, so therefore I cannot send it to you as a sample.

What I can do, if you are willing to zip your database and email it to me, I will try and set this up for you so you will be able to see exactly how it works,

My email address is part of my sig line. You will have to zip your database as my fire wall will hit any attachment other than a zipped file with a photon torpedo.
Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com