| Author |
Where to locate front end and backend?
|
|
| Steve M 2006-02-09, 3:24 am |
| 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
| |
| Tom Lake 2006-02-09, 7:24 am |
| "Steve M" < baz100uknosp@hotmail
.com> wrote in message
news:uPn3HqVLGHA.2628@TK2MSFTNGP15.phx.gbl...
> 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?
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
| |
| Steve M 2006-02-09, 7:24 am |
| 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
"Tom Lake" wrote:
> "Steve M" < baz100uknosp@hotmail
.com> wrote in message
> news:uPn3HqVLGHA.2628@TK2MSFTNGP15.phx.gbl...
>
> 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
>
>
>
| |
| Tom Lake 2006-02-09, 7:24 am |
| "Steve M" <Steve M@discussions.microsoft.com> wrote in message
news:2C7B5F90-F44E-43E4-9260- 81C6243909D5@microso
ft.com...
> 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
| |
| Tony Toews 2006-02-09, 1:24 pm |
| "Steve M" < baz100uknosp@hotmail
.com> wrote:
>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
--
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
| |
| Tony Toews 2006-02-09, 1:24 pm |
| "Tom Lake" <tom_lake@srmtenv.org> wrote:
>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
--
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
| |
| Steve M 2006-02-09, 8:28 pm |
| Many Thanks
Steve
"Tony Toews" <ttoews@telusplanet.net> wrote in message
news:uu3nu1daq6vbqp9
momhffeaf3iphnjlbe0@
4ax.com...
> "Steve M" < baz100uknosp@hotmail
.com> wrote:
>
>
> 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.
>
>
> 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
>
> --
> 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
| |
| Tom Lake 2006-02-09, 8:28 pm |
| >>If you're
>
> 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.
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
| |
| Tony Toews 2006-02-10, 3:24 am |
| "Tom Lake" <tlake@twcny.rr.com> wrote:
>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
--
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
|
|
|
|