Can frontend remain on server instead of on multiple PC's

kbrooks

Still learning
Local time
Today, 11:50
Joined
May 15, 2001
Messages
202
Everything I've read about splitting a database has talked about leaving the backend on the network server and putting the frontend on individual PC's. Is there any reason the frontend couldn't stay right where it is on the network server, and put a shortcut on the desktop?

A second question: when is it necessary to split a db? All the db's I've made have been for 4 users or less, usually 1, and I've never had a problem with it. But I'm not sure if that's pure luck or not.

I made a copy of my db and tried to split it this morning and got an error. On reading through old posts, I think it's because I didn't go into the linked table manager, so I'm condering trying again. I'm just not sure what I'll gain by splitting it.
 
If you have multiple people using the same problem you have to be careful of temporary tables, as access won't handle it for you.

What I've (just) done when a temporary table is needed it creates a copy with a unique name based on the windows username.
 
I guess I'm not sure what you mean by temporary tables...
 
ah:) I mean tables that are local to the front end, and not in the backend.

I normally use them for complicated reports or forms.
 
Splitting the Db has distinct advantages but also a couple of pitfalls. One of the main advantages is that your backend contains all the data storage and sits on the server usually, so it is (in theory) more likely to be backed up. Also because you have split the data from the graphical interface (or frontend) it means that you can make as many changes to the look and feel of the Db, add forms, reports etc without having to distribute the whole database again.
Having the frontend on the local pc with the backend on the server improves performance as the local pc chugs out the queries and graphical info whilst the backend just supplies the info. and the data storage backend will always have the most up to date info.

If you run the whole Db from the server, with only a shortcut on the local pc, you will see a marked performance hit as the server load will increase proportionately (possibly) to the number of users accessing it.

A downside is that you have to maintain the table links and hope that the server does not go down too much.

There are a myriad of posts splitting the Db, search the forum for the past discussions.
 
OK, but I don't think I'll have any temporary tables. This is a pretty straightforward, uncomplicated database. I'm just unsure if I need to bother with splitting it, and if I do, why the frontend can't remain on the network server with the backend.
 
Front end on server is sometimes only choice

I created a system for teachers to create purchase orders and split it into FE/BE(tables). Both parts were put on a server. Teachers could access the front end from any one of the district's computers (over 400 in offices, labs, classrooms etc) so it was not feasible to load a front end on each. I tried using the server to "copy" a version of the FE to the individual computer being used, but the gain in processing time was offset by the download problems. They logged into their "home" directory on the server and found a shortcut there to fire the FE on the server.

I did use the UNC naming convention for the BE links since different computers mapped different drive letters. It has worked with up to 10 simultaneous users. There was a little slowdown in response time but nothing that was all that distracting. System was running mostly Win98/95 with Ac97 on a Novell network.
 
kbrooks wrote
<<
Everything I've read about splitting a database has talked about leaving the backend on the network server and putting the frontend on individual PC's. Is there any reason the frontend couldn't stay right where it is on the network server, and put a shortcut on the desktop?
<<

Yes you can store the FE on a server. That's the way I set up apps in my shop. It helps to have a high-speed local network. If not then you will suffer a little performance loss by storing FEs on a server.

As other posters mentioned, do not create any temporary tables on a server.

RichM
 

Users who are viewing this thread

Back
Top Bottom