Access database

  • Thread starter Thread starter Gwen
  • Start date Start date
G

Gwen

I have a database that opens with a switchboard page. Clicking one of the
controls takes you to another switchboard page where the controls open forms
to enter or edit data. It is a multi user environment. I've been encountering
a problem where some users click the control on the second page to open a
form and the control appears to be pressed, but nothing happens (one control
opens the form in add mode and another opens it in edit mode). This occurs
intermittenly to different users at different times. At the same time that
some users encounter this problem, other users do not.
 
first point of resolution is to be sure that this is a split database and
that each user is operating their own individual front end application.
 
The database is split, there is one front end accessed via a link on our
intranet as opposed to having a front end loaded on individual work stations.
The actual drive the front end is located on is not visible/accessable to the
end users.

Gwen
 
Each user should have his/her own copy of the front-end, ideally on his/her
hard drive. Splitting the application into a front-end and back-end, but
sharing the front-end, really doesn't buy you anything.
 
The problem is the number of work stations that it would have to be installed
on, and also managing any design changes to the front end.
Would creating my own form to navigate through rather using the switchboard
manager be of benefit?

Gwen
 
A different form will have no benefit here. You reall need to deploy a copy
of the front end to each user.
Managing version updates is not that difficult. There are automatic front
end updaters you can download (can't find a link right now or I would send
it), but it is also simple enought the create a .bat file that copies the mdb
from a specific network folder the the user's computer.

Here is an example of a .bat file for an application that is updated from
the network server every time it is loaded. In this case, it not only
ensures the user has the most current version, but there are several local
tables used in reporting that cause some bloat, so this keeps the file size
down without a compact/repair as well as keeping the version up to date:

Copy "O:\Installation\RealPro Install\Update MDE\*.*" "C:\Program
Files\RealPro\"
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\Program
Files\RealPro\REALPRO.mde" /runtime
 
Thank you for your advice. I will need to speak to our IT department about
trying your suggestion. Hopefully they will be able to accommodate with
deploying a front end to each user and allowing the automatic front end
update. Thanks again.

Gwen
 
IT involvement should not be required.
But, this is a clue to an additional issue.
All users need to have read, write, and delete permissions on the network
folder where the backend mdb is placed. Without these rights, an ldb file
cannot be created and this will certainly result in locking issues in a multi
user environment.

If the proper rights are assigned, then all you need to do is put the master
copy of the front end in the folder with the back end where it can be copied.

If IT refuses to grant the rights described above, you will never have a
successful multi user implementation.
 
A I mentioned before, the number of work stations where a front end would be
required is many. It would not be feasible to manually visit each station to
install a front end. It would need to be a global install which I think would
require IT involvment. The back end currently resides on a network folder;
the permissions to the network folder are already established and allows for
the creation of an ldb file. The front end also currently resides in the same
folder. Only a limited number of individuals are able to navigate to this
drive/folder.

Perhaps I'm not fully understanding the .bat file, where it resides and how
it is activated.

Gwen
 
It would not take a visit to each workstation for the initial install of the
..bat file.
Here is all you need to do.
Create a shortcut on your desktop that does the copy from where the front
end is currently located to a specific folder on a user's computer and then
launches your application when the copy is done.
Right click on the shortcut and select SendTo, Mail Receipient. Just email
a copy to each user with instructions for them to copy the shortcut to their
desktop.

That is all you need to do.
 
The problem is the number of work stations that it would have to
be installed on, and also managing any design changes to the front
end.
Click to expand...

This is a problem that has been solved many times, the most
successfully (in my opinion) by Tony Toews's AutoUpdater. Google it.
 
Gwen said:
A I mentioned before, the number of work stations where a front end would
be
required is many. It would not be feasible to manually visit each station
to
install a front end. It would need to be a global install which I think
would
require IT involvment.
Click to expand...

Actually, have them read my article. here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

At the end of the day, they installed word on each computer. At the end of
the day, they install excel on each computer. in fact, likely for the last
20+ years they installed EVERY application on EACH computer. Now your
telling me that you built an application, but you NOT going to install it on
every computer like you done with ALL OTHER software? You don't think this
is a strange attitude on the IT department? It sounds like the IT department
does NOT know the difference between a document like word, and that of
application that you or your developers built.

since every other software application is installed on EACH computer, then
why not yours?

You mean if ONE person in the building has a problem with Excel, then you
want EVERYONE in the building to have the same problem?

You have to think about his......

You can roll your own update system in a hour or two, or simply using one
like tony's free updater here:

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

There is ABSOLUTE no excuse for this type of development process in which
everyone other software your have gets installed on EACH computer, but then
you then simply diss out this idea for YOUR software? Why would your
software be treated different when word, or excel, or simply accounting
software?

It like your in a form for cars and you telling me that you don't believe in
changing the oil in the car...but then are asking why your having problems?
If one user has a problem in the front end...then others users can suffer
the same damage if they all are in the same front end. Why would you risk
your reputation and stability of your work and do things different then how
all other software is run on those computers? If you have too many problems,
it very likely your put your job and reputation at stake in which they
replace you because your application is not performing well. Keep in mind
just like a bad car that you don't trust for a trip you are about to take,
your users will feel the same way about your software. Once they loose
confidence in your application, it hard to get it back and have users trust
your system. You need to do EVERYTHING to ensure that your stuff runs
well. If your software has too many problems then users will perceive
this lack of performance. Your users will think what you have is kind of ok,
but is 2nd rate quality. You don't want to give your users the idea that
your application needs to be replaced with something more professional and
robust.

I not trying to sound hard here on you, I am just trying to give you the
"sense" that there are consequences not doing things right and this can
be a FAR greater cost then just some egg on your face...but in fact can
jeopardize your whole work and efforts.

I **want** you to succeed in your efforts.
 
Gwen said:
Perhaps I'm not fully understanding the .bat file, where it resides and
how
it is activated.
Click to expand...

Typically it would reside in the same folder as your back end file - I have
another read-only folder there called "Download" which contains the batch
file, the batch file's shortcut and the front end mde. Running the shortcut
runs the batch file which copies the shortcut to the users' desktops, the
mde to their profile "temp" folder and then launches it. Tried and tested,
works a treat and no IT dept involvement at all.

Regards,
Keith.
www.keithwilby.com
 
Back
Top