Access and networks

  • Thread starter Thread starter alicia
  • Start date Start date
A

alicia

I am being told by a large organization that I am working
with that they will not support access databases on the
network due to too many errors that occur with this
application over a network. I have experienced problems
where the database file corrupts for an unknown reason
though usually when I am trying to do move a large amount
of data via remote access to the institution network.
Does anyone have any experinces to support or negate
using this application (solely MSAccess, no VB) on a
large network? Thanks in advance.
 
The issue is the JET database engine, not Access. It is not true to suggest
that the JET database engine causes errors in a networked environment, but
it is certainly true that the JET database engine, like any file-server
database engine, is more vulnerable to network problems and improper use
(e.g. users switching off PCs without closing the application) than a
client-server database such as SQL Server.

The best course of action for the organisation in question would be to
identify and fix the real causes of the problem. Unfortunately, though,
you're unlikely to change their minds about JET. That attitude toward JET
has been deeply ingrained in corporate IT for a long time now.
 
and rightlfully so. The Jet database structure is by
default sharable, but it is not a viable solution for
large companies that may be using a WAN or slow LAN. The
inherent nature of the Jet Database (especially a shared
jet dB) predicates that it be used in a small structured
environment.

For a large company, using a formal SQL server (of some
type)is the preferred method. Try MySQL. It is free, fast,
easily implimented, and is a true SQL server.
 
I have created and deployed numerous Access applications (from version 2.0
to 2002) on networks since 1995. I have found that Access database
applications are very stable and non-problematic when designed and set up
properly on a stable network. One of the reasons why this product is such a
huge seller for Microsoft is that corporate America *has* embraced its use.
However, Access can be the proverbial "canary in the coal mine" when running
on networks that are not properly equipped, configured or maintained.

Should Access be used for *all* types of databases in an organization?
Obviously, no; enterprise-critical data management and storage (for example,
large financial systems, order entry systems, etc.) are generally not
appropriate for Access. Also, as far as I know, Access does not run well
on a WAN; and when setup properly, it runs acceptably on Citrix.


Generally, the steps to set up an Access database properly for multiple
users on a network are as follows:

1. If you have not already done so, split the application into a Front-End
and a Back-End. The Front-End (FE) will contain all Queries, Forms,
Reports, Modules, Macros and local-use tables. The Back-End (BE) will
contain all tables to be shared among users.

2. The BE will reside in a folder on your server, where full permissions
for each user will be granted (Read, Write, Create, Delete, Execute).
Note: On the server, OpLocks should be set to 'Off'.

3. In the FE, Link to the tables in the BE. To avoid problems with
changing drive mappings, link to the BE tables using the full UNC, starting
with My Network Places and drilling down through folders until the actual
database name of the BE is found.

4. An individual copy of each FE will reside on each user's computer. For
ease of distributing updates to FEs, see:
http://www.granite.ab.ca/access/autofe.htm which describes an AutoUpdater
for front-ends, developed by Access MVP Tony Toews.

5. Additionally, a copy of the most current FE in use by users should be
kept on the server. You will do your maintenance/update programming on your
own copy of the FE on your own computer. When updates are ready to be
distributed, you'll copy your modified FE to replace the one on the server.

In addition, help, advice, code, etc., is available in these Access news
groups for most issues which might arise on network or remote setups.
 
Thanks for your input.
My application will be for less than 10 users in this
large netwrok environment. Do you think that I can still
use Access instead of MySQL for this small of audience?
 
Thanks so much for your input!
-----Original Message-----

The issue is the JET database engine, not Access. It is not true to suggest
that the JET database engine causes errors in a networked environment, but
it is certainly true that the JET database engine, like any file-server
database engine, is more vulnerable to network problems and improper use
(e.g. users switching off PCs without closing the application) than a
client-server database such as SQL Server.

The best course of action for the organisation in question would be to
identify and fix the real causes of the problem. Unfortunately, though,
you're unlikely to change their minds about JET. That attitude toward JET
has been deeply ingrained in corporate IT for a long time now.

--
Brendan Reynolds (MVP)
(e-mail address removed)




.
Click to expand...
 
Depending on the size and scope of the database, yes.
Also, if you are publishing the database across the wan, I
would use some sort of terminal service rather than direct
access of the dB (creating a shortcut directly to the dB).

The terminal services allow users to "Log onto" a host
machine and all data access occurs on that machine only!!
This way, the database can stay resident to the local
machine and not be broadcast across the WAN. The user just
gets "screen shots". All work is done on the terminal
server, not the clients machine.

If the users are in the same general vacinity (basically
in the same building) of each other than direct access is
OK as long as the database is not very large. This is a
very generalized statement, and alot of things are
involved with determining if it will work or not.
Typically, 10 users is about right for an Access dB.

Under no conditions would I give direct access of the dB
across a WAN, regardless of how many people access it.
 
Back
Top