Why a front end for each user?

K

Kjell Harnesk

Hi!
Almost every answer that speaks about the importance of splitting into a
front end and a back end states that there should be a copy of the front
end for each user. Is this so that users can create queries and reports of
their own or is there another reason? I have a front end that is used AS IS
of all the users and there is no need to alter things in the front end
other than by the developer (me). Is it not better to have just one front
end on a network share in this case? Much simpler to distribute new
versions.
 
S

SusanV

Well, for one thing, if one user's PC crashes hard, only their copy has the
chance of being corrupted.
 
S

samuelgreene

...adding users custom queries quickly becomes a pain - as they fail to
make requests and wonder where their queries are when they grab a new
version. Make sure you spell this out to all users or they may become
irritated.
 
K

Kjell Harnesk

..adding users custom queries quickly becomes a pain - as they fail to
make requests and wonder where their queries are when they grab a new
version. Make sure you spell this out to all users or they may become
irritated.

I´m not sure I understand what You mean, in my case all users have the same
front end, there is no need for user specific queries or other things. It
seems easier to just have to update one front end when changes are made.

To Susan - There is a backup, in case of a crasched front end it's just a
matter of copying the backup.

To Sandra - The database is split, but there is only one front end. In my
opinion this makes maintainance easier than with multiple front ends.

The only point that makes sence to me is the one about performance but this
has not been a problem so far, there are only a few simultaneous users. So,
unless someone comes up with a better reason I will stay with one front
end.
 
J

John Vinson

..adding users custom queries quickly becomes a pain - as they fail to
make requests and wonder where their queries are when they grab a new
version. Make sure you spell this out to all users or they may become
irritated.

or better, give them a .mde and no design permissions on new queries.

The small subset of power users who can be trusted not to create a
Delete query that will erase the last two years' work (or do something
equally dreadful) can be given a SEPARATE .mdb frontend linked to the
backend, so they can write their own custom queries.

John W. Vinson[MVP]
 
A

Albert D.Kallal

..adding users custom queries quickly becomes a pain - as they fail to
make requests and wonder where their queries are when they grab a new
version. Make sure you spell this out to all users or they may become
irritated.

a good point. However, one does assume that as you walk the road of learning
ms-access, when you reach the point of deploying applications to your user
base, they never see the ms-access interface, and never see the query
builder anyway.

It is kind asking too much of your users to say here is a room booking
system, but first go and lean how to write sql........

So, for most part, users really never should see the tables and query view
system anyway. You want to provide a interface for the users...

For prompting of reports, and parameters, it is best to build some prompt
screens. I give some ideas here

http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html

and, for hiding the access inteface, and WHY i use custom menus..here is
some screen shots of an appcation with the ms-access part hidden...
http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm
 
P

(PeteCresswell)

Per Kjell Harnesk:
I´m not sure I understand what You mean, in my case all users have the same
front end, there is no need for user specific queries or other things. It
seems easier to just have to update one front end when changes are made.

It's even easier if you put a .BAT file, .CMD file, or some utility in place so
that the latest version always gets automagically downloaded to each user's PC
when they click on your application's icon.

Resolves the issue of one user taking the whole app down by corrupting it, and
makes elevations of new versions easy for you and transparent to everybody.

If I posted a sample .BAT file, it would probably scare you off.

Somebody else will chime in with the utility.
 
K

Kjell Harnesk

It's even easier if you put a .BAT file, .CMD file, or some utility in place so
that the latest version always gets automagically downloaded to each user's PC
when they click on your application's icon.

Resolves the issue of one user taking the whole app down by corrupting it, and
makes elevations of new versions easy for you and transparent to everybody.

Good point! But will the copying of a 15 MB front end over a rather slow
network p-ss the users off if this is what happens every timne they start
the applikation? But maybe it is not much slower than reading the
applikation into memory from the network?
 
P

(PeteCresswell)

Per Kjell Harnesk:
Good point! But will the copying of a 15 MB front end over a rather slow
network p-ss the users off if this is what happens every timne they start
the applikation?

No, because the .BAT file or utility knows whether the latest version is already
there and only copies if it is not.
 
K

Kjell Harnesk

Per Kjell Harnesk:

No, because the .BAT file or utility knows whether the latest version is already
there and only copies if it is not.

Sounds like something I would like to have. Could You consider sharing an
example batfile with the community?
 
P

(PeteCresswell)

Per Kjell Harnesk:
Sounds like something I would like to have. Could You consider sharing an
example batfile with the community?

Ok, but it's not pretty.

Be prepared to spend a few hours figuring the thing out.
Once you understand what's going on, cloning it for another app
is pretty easy.

It's been working for me for about five years now.

Also, don't overlook whatever utilities that have been written by others to do
the same thing. Can't tell you where to find same, but somebody in the NG
should have a URL.



The example below is for an application named "Returns".

There a are three files involved. The first two live in the application's LAN
directory in a folder named "BAT". The last one lives at the root of the
application's LAN directory, the same as the app. I do this because it's
edited
each time we elevate a new version and having it there is simpler and less
error-prone than mixing it in with the .BAT files.

1) Returns_Go_1.bat.
A small .BAT file that builds some memory variables that tell where things
are. This is what gets executed by the icon on the user's desk. The last
thing it does is copy the second file to the user's PC, rename it to a .BAT
file, and execute it.

2) Returns_Go_2.txt.
The main file. This is where the heavy lifting gets tone. It lives
in the LAN/BAT directory as a .txt file, but gets renamed when the first
.BAT file copies it down to the user's PC.

3) Version.txt.
This tells the .BAT process what the latest version of the app is.


Knowing which version is the latest hinges on how the application is named.

I put the version number in the app's name. e.g. ReturnsApp.023a.mdb is version
23a of the app. ReturnsApp.024k.mdb is version 24k.

There is some more explanation at the end of the second file.


I don't know what the various NG processing middlemen will do with the text
flow of the examples. If they look too nasty on your end, flip me an email
to FirstName dot Lastname at FatBelly fullstop com and I'll email you back a
..ZIP file.



Returns_Go_1.bat:
-------------------------------------------------------------------------------------
SET ScriptPath=%~f0


@ECHO OFF

ECHO .
ECHO . --------------------------------
ECHO . Making sure we have C:\TEMP
ECHO .

IF NOT EXIST C:\TEMP MD C:\TEMP


ECHO .
ECHO . --------------------------------
ECHO . Setting application-specific memory variables

SET AppName=Returns
SET AppDescr=Returns Analysis Tool

SET AppDirLAN=H:\Returns
SET BatDirLAN=%AppDirLAN%\Bat
SET BatPathLAN=%BatDirLAN%\%AppName%_Go_2.txt
SET AppDirLocal=C:\Temp

SET IniPath=%BatDirLAN%\%AppName%.ini
SET SecPath=%BatDirLAN%\SYSTEM.MDW
SET VerPath=%AppDirLan%\Version.txt


ECHO .
ECHO . --------------------------------
ECHO . Copying/Executing the main .BAT file

IF NOT EXIST %BatPathLAN% GOTO AbendBatMissing

COPY %BatPathLAN% %AppDirLocal%\%AppName%_Go_2.bat
Call %AppDirLocal%\%AppName%_Go_2.bat

:ExitNormal
GOTO :EOF



:AbendBatMissing

COLOR E0
ECHO .
ECHO .
ECHO .
ECHO .------------ FATAL ERROR -------------------
ECHO .
ECHO . Cannot Run %AppDescr% because:
ECHO .
ECHO . %BatPathLAN% not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO .--------------------------------------------
ECHO . This error came from: %ScriptPath%
ECHO .
PAUSE
GOTO :ExitNormal

:* ---------------------- END OF ...GO_1 ------------------------------
-------------------------------------------------------------------------------------





Returns_Go_2.txt:
-------------------------------------------------------------------------------------
@ECHO OFF
:* (Please refer to end of file for explainatory remarks)

:* ------------------------------
:* Capture script name/path into memory variables
:* Technically, this may seem redundant, but it makes
:* for a little lesss gobbeldygook in the code when we
:* want to refer to these values

SET ScriptName=%~n0
SET ScriptPath=%~f0


:* -----------------------------Begin Main Procedure ----------------------------------------
:Main


:* (application-specific memory variables were set in ..._Go_1)

TITLE %AppName%

ECHO .
ECHO . --------------------------------
ECHO . Verifying/creating local directory
ECHO .

IF NOT EXIST %AppDirLocal% MD %AppDirLocal%

ECHO .
ECHO . --------------------------------
ECHO . Checking for version file...
ECHO .
IF NOT EXIST %VerPath% GOTO
AbendVersionTxtMissing

ECHO .
ECHO . --------------------------------
ECHO . Copying/Executing the Excel module that contains ROR and
ECHO . other calcs. This is NOT essential for the app to run,
ECHO . although without it some users may not have those calcs
ECHO . available on exported spreadsheets

COPY %BatDirLAN%\FUNCTION.xla %AppDirLocal%\FUNCTION.xla
COPY %BatDirLAN%\FUNCTION.xla C:\FUNCTION.xla


:VerCopy
:* ----------------
:* Copy Version.txt to .BAT on local drive and then execute it
:* This will set memory variables containing latest version number for each app
and
:* tell us whether-or-not we want to force a refresh of existing app

ECHO .
ECHO . --------------------------------
ECHO . Getting version numbers...
ECHO .
COPY "%VerPath%" %AppDirLocal%\%AppName%_Version_Set.BAT
CALL %AppDirLocal%\%AppName%_Version_Set.BAT

SET AppPathLAN=%AppDirLAN%\%AppName%App.%AppVersion%.mdb
SET AppPathLocal=%AppDirLocal%\%AppName%App.%AppVersion%.mdb



:AppCheck
:* ----------------
:* Check for existing app version on C:
:* No sense copying it down if it already exists...
:*
:* Although we may have wanted to force a new copy anyhow
:* by setting "AppRefresh=Yes" in Version.txt.

ECHO .
ECHO . -----------------------
ECHO . Checking latest version of application on your PC...
ECHO .

IF NOT EXIST %AppPathLocal% GOTO AppCopy
IF %AppRefresh%WhoopieDoopieDoooo==WhoopieDoopieDoo GOTO AppStart

IF %AppRefresh%==YES GOTO AppCopy
IF %AppRefresh%==Yes GOTO AppCopy
IF %AppRefresh%==yes GOTO AppCopy
GOTO AppStart


:AppCopy
:* ----------------
:* Copy the app down to user's C: drive
:*

IF NOT EXIST %AppPathLAN% GOTO AbendAppMissing
DEL %AppDirLocal%\%AppName%App.*.mdb
ECHO .
ECHO . -----------------------
ECHO . Copying new version of application down to your PC....
ECHO .
COPY %AppPathLAN% %AppPathLocal%

:AppStart
ECHO .
ECHO . -----------------------
ECHO . Starting MS Access...
ECHO .

START /B /HIGH /MAX "'Returns' Startup" MSACCESS.EXE %AppPathLocal% /ini
"%IniPath%" /wrkgrp "%SecPath%" /Excl

SET RET=0
GOTO :EOF
:* -----------------------------End Main Procedure ----------------------------------------

GOTO :ExitNormal



:AbendAppMissing
COLOR E0
ECHO .
ECHO .
ECHO .
ECHO .------------ FATAL ERROR -------------------
ECHO .
ECHO . Cannot Run %AppDescr% because:
ECHO .
ECHO . %AppPathLAN% not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO .--------------------------------------------
ECHO . This error came from: %ScriptPath%
ECHO .
PAUSE
GOTO :ExitNormal



:AbendVersionTxtMissing
ECHO OFF
COLOR E0
ECHO .
ECHO .
ECHO .
ECHO .------------ FATAL ERROR -------------------
ECHO .
ECHO . Cannot Run %AppDescr% because:
ECHO .
ECHO . %VerPath% not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO . ECHO .--------------------------------------------
ECHO . This error came from: %ScriptPath%
ECHO .
PAUSE
GOTO :ExitNormal


:ExitNormal
GOTO :EOF

:* =============================================================================
:* (these remarks are so lengthy that they were actually slowing down the execution
:* when they were up in the beginning of the file - so we moved them here)
:*
:* PURPOSE: To download the latest version of one of several applications
:* and start it up under MS Access.
:* ACCEPTS: (nothing)
:* NEEDS: - A text file named 'Version.txt'. Refer to the 'VerPath'
:* parameter below. A sample file is appended in remarks at the end
:* of this .BAT file.
:*
:* NOTES: 1) Remarks slow execution too much when a .BAT file is run over the LAN.
:* Therefore we have a little root .BAT file on the lan ("..._Go_1.bat")
:* that copies this .TXT file down to C:\TEMP and renames it to ...BAT.
:* This speeds up execution a *LOT*.
:*
:* 2) Some of the memory variables may seem a little gratuitous at first
:* (like %AppPathLocal%), but anywhere a concatonation of values exists and
:* is referenced in more than one place we created a new variable to reduce
:* on the chance of a type error in one of those places.
:*
:* 3) This is all dependent upon a three-level naming convention for your app
:* that begins with the app name, includes a three-digit version number,
:* and ends with ".MDB".
:* e.g. ReportHelperApp.016.mdb would be version 0.16 of the Report Helper application.
:*
:* 4) This is intended to be called from a shortcut with a command line that
:* reads something like: D:\ReportHelper\Bat\ReportHelper_Go_1.bat
:*
:* 5) Memory variables that need to be set for each application are all
:* in the preceeding .BAT file "...Go_1.BAT"
:*
:* AppName - The name of the application as it appears in the .mdb file name.
:* SB exactly the same as the parameter for that app.
:* AppDescr - User friendly short description for error messages
:*
:* AppDirLAN - The DOS path or UNC that points to the directory where the
:* application is to be copied from
:* BatDirLAN - The DOS path or UNC that points to the directory where
:* the big .BAT file is to be copied from
:* AppDIrLocal- The directory on the user's PC where the application and
:* big .BAT file are to be copied to. SB C:\TEMP.
:* Change it at your own risk!
:*
:* IniPath - The full DOS path or UNC to the .INI file used by the application
:* This is the one we put on the Access command line.
:* NB: Each app should try to use the same .INI file, but we do it
:* this way in case somebody wants their very own....
:* SecPath - The full DOS path or UNC to the .MDA file we use for security
:* VerPath - The full DOS path or UNC to the little .TXT file that contains
:* latest version number of each app.
:*
:* 5) Last, but not least, is the "Version File" - currently named "Version.txt".
:* It loads two variables:
:* ....AppVersion, which tells what version of the app to run
:* ....AppRefresh, which tells whether-or-not we want to download the app even though
:* it is already on the user's PC
:*
:* =============================================================================
 
J

John Vinson

Once you understand what's going on, cloning it for another app
is pretty easy.

It's been working for me for about five years now.

Also, don't overlook whatever utilities that have been written by others to do
the same thing. Can't tell you where to find same, but somebody in the NG
should have a URL.

This .bat file seems to be pretty comprehensive - I'm impressed!

If you want to compare it with an alternative, I really like Tony
Toews' AutoFE Updater:

http://www.granite.ab.ca/access/autofe.htm

John W. Vinson[MVP]
 
P

(PeteCresswell)

Per John Vinson:
If you want to compare it with an alternative, I really like Tony
Toews' AutoFE Updater:

http://www.granite.ab.ca/access/autofe.htm

I think that's the utility-program alternative I was groping for.

The .BAT file works, seems fairly bullet proof... and I use it because I have
it. But I suffer periodic bouts of guilt about leaving it there for the
unfortunate "next guy" who has to maintain one of my apps.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top