Updating Front End Strategy

ebodin

Registered User.
Local time
Today, 08:55
Joined
Apr 25, 2005
Messages
15
I have a DB that I just distribute a shortcut to a front end on a network location. Then when I update the front end I delete the old one and give the new one the same name as the old one, so everyone's shortcut still works, but the FE has changed.

I haven't seen anyone else do this, which makes me nervous. Can you see any potential problems with this strategy?

thanks.
 
Are you stating that all of your users are opening the same front end file on a server

If so then I suggest that you split your db. Each user should have their own copy of the front end installed onto their computer. Each front end is linked to one back end. The back end only holds the tables that the users need to share. The front end on each users computer holds everything else.

Search this forum for this topic has already been discussed if a few thousand threads.
 
I'm aware of the split database idea. I have implemented this. However, instead of installing FE's on everyone's computer. I distribute a shortcut to the front end. When they open the shortcut, it downloads the front end to their computer (I think) and then allows the user to search the DB (it's read only).

My question is - since I haven't heard of anyone doing this - what problems do you see arising?

When I distribute a link does it really download the front end, or does it run it from the network location? Will this support multiple users?

thanks.
 
I have been doing this same thing for nearly 2 years now without a hitch. My DB is split into FE and BE and they both reside on the server. It makes it easy to update the application as there is only one DB to change and as long as the name and location remain the same, you are golden with the shortcuts. No, the DB is not downloaded, it is just opened from the server. All of your users will need to have Access installed on their machines.

You will take a slight performance hit as compared to the users having the FE on the local machine so you should take that into consideration.
 
What is your environment like? How many users do you have? Is your DB read only?

I have a read only DB (to the end users) that is available to everyone in the factory (on the Intranet), but only used by a handful of people per day. We have a link from our webpage that launches the application (everyone has Access 2003). It has worked well so far, but I hadn't seen anyone else doing this, only those trying to figure out how to update FE's.
 
I still have my database as one single application and I am worried because there seems to be alot of people who split the database. Maybe by not having a split database I am doing things the wrong way, or the old way, or maybe I am compromising my databases.

From what I can gather, linked tables are absolute links. This makes it very hard to put your database onto a CD and sell it to other agencies.

I know this has been discussed a thousand times. I have searched the forum, and even Googled, and there seem to be many solutions that all hold their own problems.

Is there any 'right' solution?
 
Using a short cut to a FrontEnd on a server means everyone is using the same FrontEnd. Having more than one user in an Access mdb/mde at the same time is corruption waiting to happen. Every user should be using their own copy of the FrontEnd installed on their own machine. Aside from the corruption issue there is a huge maintenance advantage to splitting. I also doubt you will find any MVP who does not recommend splitting into FE/BE. That has to mean something. It is *your* application and it *will* work without splitting so the decision is yours, since we're only talking about reliability after all.
 
yhgtbfk said:
I still have my database as one single application and I am worried because there seems to be alot of people who split the database. Maybe by not having a split database I am doing things the wrong way, or the old way, or maybe I am compromising my databases.

From what I can gather, linked tables are absolute links. This makes it very hard to put your database onto a CD and sell it to other agencies.

I know this has been discussed a thousand times. I have searched the forum, and even Googled, and there seem to be many solutions that all hold their own problems.

Is there any 'right' solution?

EVERY database that is multi-user or supported remotely NEEDS to be split. There is absolutely NO question about this. That is the "right" solution. However, I don't go so far as to say the FE must be located locally. It is true that you WILL get better performance from local FEs. But if you only have a few users, you can use a shared FE. Most of the maintenance advantages of a split database apply to a shared or a local FE. Corruption occurs more in handling data, so by splitting you greatly reduce the chances of corruption.

I gave you links in answer to another post that show you how you automate the process of relinking your tables. You can use that code when selling your database.
 
I suppose that it has worked for me to split the DB, but provide shortcuts on desktops to the FE that the user needs (instead of installing the FE on the user's desktops) because the FE's that I supply in this way are read only, and because I don't have a large number of users at one time. Data is not entered from those FE's. Maybe the problem that I would have if I get too many users is that the DB will slow down or freeze up, but not become corrupt?
 
If the FEs are just used for viewing and reporting, that would help reduce the possibility of corruption. The consensus I hear is that Access starts to slow down when there are more than 20 concurrent users.
 

Users who are viewing this thread

Back
Top Bottom