Front End and Back End General Questions

[Guest]

I have just finished splitting all of the Access databases I am now in charge
of on our network to Front and Back End.

Before I came along, the main two databases where this way already.

But I am a bit confused. The Front Ends of these two databases were still
on a network drive. When someone accessed the Front End, they did it via
ashort cut on their desktop that points to the FE. So everyone points to
that same front end.

But doesn't this kind of defeat part of the purpose of a front end?
Shouldn't the front end reside independantly on whoever's desktop that needs
it? Then, wouldn;t it be best to incorporate some type of version number
checking so if someone's front end is out dated, they go and fetch the
current one.

What errors will I avoid in having multiple front ends pointing to the same
back end rather than shorcuts to one front end pointing to the back end. Make
sense?

 

[Allen Browne]

You are right: the main point of splitting the database is so everyone can
have their own, independent copy of the front end.

The best performance is achieved by running the front end from the user's
local drive: quicker access, less network traffic.

Some network admins prefer to place the front end in the user's workspace on
the server, as it makes it easier for them to manage. While this is slower
and creates more traffic, it does work. An alternative is to script to copy
the front end to the user's machine as needed, e.g.:
http://www.granite.ab.ca/access/autofe.htm

If everyone opens the same front end, there can be problems with data
corruption, filtering, and multi-user conflicts. If the developer used
temporary tables in the front end, you may also end up with bad data in
reports based on those temp tables, as users end up overwriting the data
others are using.

Splitting actually reduces performance, so everyone in a single split front
end is almost the worst possible arrangement (other than that you can
replace the front end without losing the data.)

 

[Guest]

Allen,

Thanks. So the "This form has been changed by another user. Click here to
save or here to discard changes" type errors will go away when everyone has
their own front end?

With each user with their own front end, error messages would probably
almost go away?

To restate your response, it sould like the one FE is for the developers
ease in terms on not having to provide a means to update FEs. One front end .
.. . ."Everybody out of the pool!!!" and, upload a new Front End??

 

[Tony Toews [MVP]]

Thanks. So the "This form has been changed by another user. Click here to
save or here to discard changes" type errors will go away when everyone has
their own front end?
Exactly!

With each user with their own front end, error messages would probably
almost go away?

To restate your response, it sould like the one FE is for the developers
ease in terms on not having to provide a means to update FEs. One front end .
. . ."Everybody out of the pool!!!" and, upload a new Front End??

Whereas using the Auto FE Updater means you copy a new FE to the server when you're
ready and the users automatically get their own copy of the FE copied down the next
time they start the app.

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

 

[Allen Browne]

Replies in-line.

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

Allen,

Thanks. So the "This form has been changed by another user. Click here to
save or here to discard changes" type errors will go away when everyone
has
their own front end?

With each user with their own front end, error messages would probably
almost go away?

Giving everyone their own front end might avoid these errors, depending on
what is actually causing them.

It might also help to create an MDE to use as the front end, so it cannot
decompile and users cannot switch to design mode.

To restate your response, it sould like the one FE is for the developers
ease in terms on not having to provide a means to update FEs. One front
end .
. . ."Everybody out of the pool!!!" and, upload a new Front End??

The single front-end file is also the poorest way of updating. Much more
flexible to update without knocking everyone out, either manually or by
scripting (when the user starts the app.)

The single-front-end-for-everyone approach is usually the result of
ignorance (not knowing why each user needs their own front end), or perhaps
laziness ("I only want to manage one file.")

 

[Guest]

Thanks Tony. I hadn't looked at Allens FE Update link yet. Guess I need to!

 

[Guest]

Thanks Allen. I will look into the FELoader you referred to.

I'm not going to go to MDE files until after I upgrade to Access '03. Then
I'll look into the FE Loading a bit more.

 

[Guest]

Here are some articles that you may find helpful:

Split the database
http://www.access.qbuilt.com/html/gem_tips1.html#SplitDB
http://home.bendbroadband.com/conradsystems/accessjunkie/splitting.html

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Tony Toews [MVP]]

I'm not going to go to MDE files until after I upgrade to Access '03. Then
I'll look into the FE Loading a bit more.

Nah, go for it now.

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

 

[David W. Fenton]

the main point of splitting the database is so everyone can
have their own, independent copy of the front end.

I though the main point of splitting was to segregate data from your
application? That applies even to single-user applications.

 

[Susie DBA [MSFT]]

splitting is called 'unnnecessary complexity'

these dipshits thrive on that sort of thing

move to Access Data Projects and you could focus on DEV instead of all
of this maintenance CRAP


seriously

plug and play
queries stay in one place-- where they belong-- ON THE FRIGGIN SERVER

sprocs and views are infinitely more powerful than silly little Access
queries

 

[Guest]

Yeah . . .I know I should.

I have split everything and cleaned some things up, but users still point to
a common MDB front end. You think if I am rattling their cage and putting
local copies on their PCs anyway, I might as well make it an MDE rather than
an MDB.

Otherwise, I'm rattling their cage once to point them to a different FE and
then rattling it again when I point them to a different - - different FE?

 

[Guest]

Otherwise, I'm rattling their cage once to point them to a different FE and

then rattling it again when I point them to a different - - different FE?

Nope. If you use Tony's AutoFE Updater, you only need to distribute a
shortcut one time. You can change the file that is automatically downloaded
at any later point in time (ie. .mdb versus .mde file) simply by making a
change in a .ini file.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Guest]

Got it.

Now, if I can take a step back for a minute <grin> Currently, as you know,
everyone points to the same FE. I realize this does not make sense. That was
my original post.

However, it has been this way for several years with only minimul problems.
I will change that, but it will require a bit of user re-education.

IN THE MEAN TIME, my biggest problem is people nosing around where they
shouldn't and trying to experiment. It's only a matter of time before someone
messes something up real good.

So, would a situation where everyone points to the same MDE front end
instead of the same MDE front end . . . at least get me a step in the right
direction?

 

[Guest]

However, it has been this way for several years with only minimul problems.

I will change that, but it will require a bit of user re-education.

The change doesn't need to be so hard. After you create a new shortcut,
using the StartMDB.exe file, test it out to satisfy yourself that all is
working fine. Make an update to your .mde file, post it, and verify that a
new copy is downloaded as expected. Then, send all of your users a copy of
the shortcut in an e-mail message. Tell them to delete their existing
shortcut to the old FE file. I would also include a UNC link to a new folder,
which contained only one file: the same shortcut. Explain in the e-mail that
they should first save the shortcut to their desktop (or the location of
their choice), and then double-click on it to start the newest version.

Here is a zipped Word document that includes information on setting up
Tony's utility:

http://home.comcast.net/~tutorme2/samples/autofe.zip

As you will see in the example provided, it is relatively easy to plant the
new .mde file in a path that is normally hidden to most users. In addition,
you can disable the Shift key, so that users cannot easily bypass an Autoexec
macro or startup form. That should help keep anyone from dinking around with
your file.

You can delete the shared copy of the FE file from the location that user's
shortcuts point to it. You can also either move the BE database to a new
folder, or rename it. That should disable your FE, in case one of your users
took a local copy. They'd have to know how to relink the FE to the BE. I
suspect that most users will follow the instructions in the e-mail that you
send out, rather than spending time futzing around with a broken shortcut.

IN THE MEAN TIME, my biggest problem is people nosing around where they
shouldn't and trying to experiment. It's only a matter of time before someone
messes something up real good.

Distributing in the compiled .mde format will prevent users from making any
design changes to forms, reports or modules. They'll still be able to
add/edit/delete tables, queries and macros. You can make the task more
difficult for them deselecting the option "Allow Special Keys" (so that F11
won't work to display the database window) under Tools > Startup... Of
course, you'll also want to uncheck the option to display the database
window. Finally, disable the shift key, so that they cannot bypass your
startup options. Most users are not savvy enough to know how to re-enable the
shift key.

So, would a situation where everyone points to the same MDE front end
instead of the same MDE front end...

Huh?


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Guest]

So, would a situation where everyone points to the same MDE front end

instead of the same MDE front end...

Huh?

Umm. . . . . . . Should have been points to the same front end MDE instead
of same front end MDB. You're "huh?" was well deserverd.

But you can practically disregard the question. I'm going to spend time
Understanding the whole Front End loader process and start down that road
immediately. Corruption hasn't been an issue so much as users stepping over
each other accessing the same FE. But I agree that, with things the way there
are now, corruption is inevitable.

Thonks so much for the additional link to the samples

 

[Tony Toews [MVP]]

Thonks so much for the additional link to the samples

Agreed. Writing user friendly documentation is one of my many
weaknesses.

Thanks to Tom.

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

 

[Guest]

OK. I set up the FEUpdater program. I created the sever directory where the
“master†front end would sit and placed the FE there.

I then created the local folder for the copy to reside in. I ran the
utility. It ran fine, and placed an ini file plus a copy of the FE in that
folder. But I assume the utility creates that folder if it is not already
there?

The the light came on! I was thinking of this utility as a “Control Panelâ€
to push updates FEs out. But does it actually resides “in between†via the
ini - - and makes sure the FE is updated every time!! If I update the
master, the user gets it next time he runs the icon on his desktop. Got it
right? It just compares file date and size?? No change, and it goes right
in. Change, it copies and goes in??

Here’s my next question (you folks are great!). I have multiple front ends
that point to multiple back ends.

Theres the “Grand Pooba†backend. The there are others. All of the front
ends need info from the Grand Pooba BE, but they also link to their own back
ends that have information more specific to their particular area, So a
typical FE has links to two backends.

In addition, the back ends are in directories determined by group rights on
a Netware server. This should’t matter, should it? Because all would need
to give common access to is the FEs, so no back end data is exposed to
unauthorized users. The utility simply won’t run?

1. Do I create a different ini for each front end and give it a descriptive
name. Or do put multiple lines in one ini and have everything copies to the
local PC. If they can access the BE, fine. If not, they can’t? Help me
understand this a bit more, will you.

2 .Every user must run the StartMDE program once to get the local folder
created and the initial FE files. But from that point on, they update by
simply clicking on the icon for each DB?

This is cool! Thanks so much.

 

[Guest]

I think I answered my own questions . . .partially.

The entire contents of the server DIR get copied. I can have it copy
everything and let Folder Rights weed out who can;t access what Back end. Or
I can set up different INIs and have them choose what "groups" apply to
them???

 

[Tony Toews [MVP]]

I think I answered my own questions . . .partially.

The entire contents of the server DIR get copied.

Correct. Typically the only thing in that folder would be the front
end MDB/MDE to be copied. Hmm, is that adequately explained on my web
pages?

I can have it copy
everything and let Folder Rights weed out who can;t access what Back end. Or
I can set up different INIs and have them choose what "groups" apply to
them???

Yes, you can setup as many INI files as you want. I've done that in
the past for a client who had some folks running the app locally and
others on Citrix servers.

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