Where to locate front end and backend?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Steve M - 09 Feb 2006 09:23 GMT

Hi
I have spilt my database as suggested for multiuser work. I just wondered
about the best place to store thefront end and backend. At present the
front end and back end are held on the staff drive. Most examples seem to
say to use the C drive on indivdual machines but we are not permitted to use
these. Only the network can be used. The backend is in one folder and the
front end in another folder.

Should I make a front end for each user, That I can update from a master?

Any advise on the file structure I should use would be appricated.

Steve

Reply to this Message

Tom Lake - 09 Feb 2006 12:48 GMT

> Hi
> I have spilt my database as suggested for multiuser work. I just wondered about
[quoted text clipped - 4 lines]
>
> Should I make a front end for each user, That I can update from a master?

Yes, that's the point of having a separate front end. Give a copy to each user
and they won't have to share it. Their response time will go down. If you're
limited to using a network drive, there's not much point in splitting up the
database AFAICS.

Tom Lake

Reply to this Message

Steve M - 09 Feb 2006 12:59 GMT

Thanks Tom.
So I can pretty much put my fe, be any where on the network.

Sorry to be a bit thick but what is AFAICS, bit of a novice at all this.

steve

> > Hi
> > I have spilt my database as suggested for multiuser work. I just wondered about
[quoted text clipped - 11 lines]
>
> Tom Lake

Reply to this Message

Tom Lake - 09 Feb 2006 13:02 GMT

> Thanks Tom.
> So I can pretty much put my fe, be any where on the network.
>
> Sorry to be a bit thick but what is AFAICS, bit of a novice at all this.

I'm the one who should apologize for using obscure language. AFAICS means As Far As
I Can See.

Tom Lake

Reply to this Message

Tony Toews - 09 Feb 2006 19:02 GMT

>If you're
>limited to using a network drive, there's not much point in splitting up the
>database AFAICS.

I respectfully disagree. There are a number of reasons to split the
MDB and give each user their own copy.

One major reason for splitting the MDB is so that you can work in
forms or reports which disturbing the users. Once you've got some
work done then you can roll out the changes without the users seeing
partially updated forms and reports and such.

Giving each user their own FE helps in that it's much easier to
distribute those updates. Otherwise when you have a new FE MDB/MDE to
give to the users you'd have to kick them all out. And that can be
an impossible task.

Let alone all the wonkiness that happens when you share an FE.

Tony

Signature

Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Reply to this Message

Tom Lake - 10 Feb 2006 01:30 GMT

>>If you're
>>limited to using a network drive, there's not much point in splitting up
[quoted text clipped - 8 lines]
> work done then you can roll out the changes without the users seeing
> partially updated forms and reports and such.

You mean you have to make changes to an application AFTER it's
released??? Why not just write it right the first time? We all know
user requirements never change and they give us a complete, accurate
set of specs from which to work so why would you ever need to make
changes? 8^)

Of course you're right. I hadn't thought of those other uses until 0.005
ms after I sent the first message!

Tom Lake

Reply to this Message

Tony Toews - 10 Feb 2006 02:33 GMT

>You mean you have to make changes to an application AFTER it's
>released??? Why not just write it right the first time? We all know
>user requirements never change and they give us a complete, accurate
>set of specs from which to work so why would you ever need to make
>changes? 8^)

BWAHAHAHAHAHA. D*MN. Now I have to replace the keyboard in my
laptop.

>Of course you're right. I hadn't thought of those other uses until 0.005
>ms after I sent the first message!

Ain't that how it goes.

Tony

Signature

Reply to this Message

Tony Toews - 09 Feb 2006 18:59 GMT

>I have spilt my database as suggested for multiuser work. I just wondered
>about the best place to store thefront end and backend. At present the
>front end and back end are held on the staff drive. Most examples seem to
>say to use the C drive on indivdual machines but we are not permitted to use
>these. Only the network can be used. The backend is in one folder and the
>front end in another folder.

The ideal situation is to copy the FE down to the users hard drive as
that would give you the best performance when the user is opening new
objects. However this isn't always practical especially in a
Terminal Server/Citrix environment.

Now as far as your IT rules do they are there for a purpose.
Basically you can't have any files on your C drive as they need to be
backed up. However Access FEs are different in that you don't care
if the hard drive gets lost. You just copy it down again and that's
that. So an argument could be made to your IT department that Access
FEs are like .exe files in that sense. However they might still not
agree.

So I'd definitely create a folder on the server for each user and put
the FE in there.

Finally I specifically created the Auto FE Updater utility so that I
could make changes to the FE MDE as often as I wanted and be quite
confident that the next time someone went to run the app that it would
pull in the latest version. For more info on the errors or the Auto
FE Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

>Should I make a front end for each user, That I can update from a master?

Yes, you should. This will virtually eliminate the possibility of
corruptions in the FE. Also sharing an FE can cause all kinds of
wonkiness and weird error messages.

Tony

Signature

Reply to this Message

Steve M - 09 Feb 2006 23:14 GMT

Many Thanks
Steve

>>I have spilt my database as suggested for multiuser work. I just wondered
>>about the best place to store thefront end and backend. At present the
[quoted text clipped - 42 lines]
>
> Tony

Reply to this Message