Database connectivity?How many users can connect at once

[Guest]

Im designing a web application for a job and I was planning on using access
for the database end, but Im not sure if access supports multiple users to
connect at once. I was wondering if it did support multiple web users to
connect to it at once and if so how many?
Thank you for any replies!

 

['69 Camaro]

Hi, Emmanuel.

Microsoft Access supports multiple concurrent users. Up to 255 users can
connect at one time. However, practical usage is about five to 30 users in
a networked environment, depending upon the complexity and transaction
activity of the database application.

Due to security issues, it is not advised to use an Access database as the
data provider for a Web site.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[david epsom dot com dot au]

First, let me say that many people have web pages
connected to Access/Jet databases, and don't have
any problems with a hundred users per day. And these
people are often running their own web servers.

However, if you are interested, here is more information.

Most web pages do not create a new connection to the
database for every web connection. Instead, a small
number of database connections are shared between all
web users. Using a separate database connection for
each web user is generally considered to be a bad thing.

Access/Jet is multi-threaded. This can cause problems:
you may wish to set jet to be single-threaded on the
server. Specifically, thread creation calls are not
re-entrant, and the system will fail if Jet tries to
create a new thread within an ASP thread creation call.
This will probably only happen if the web page is heavily
loaded, and there are also a specific connection technique
to avoid the problem.

Backup and update can be a bit of a problem when using
an Access/Jet database. You can't easily connect to an
Access/Jet database on an internet web server (you need
to either go to the server or enable file sharing), and
you can't copy or overwrite the database while it is in
use. This sometimes means that you actually have to
stop the web server in order to back up or update the
database.

Gunny: I'm not aware of any specific security problems
with using an Access/Jet database on a web server. It
was SQL Server that once brought the web to it's knees,
and had d'd good shot at it on an earlier occasion.
As with SQL Server, all Jet service packs should be
applied, and access through to Windows should be disabled.

(david)

 

[Arvin Meyer]

That really varies with the design of the database. As I write this I have
51 users currently connected to my JET data tables. 30 are connected via the
LAN, 6 via Terminal server sessions, and 15 through an asp application. Some
of the users have multiple front-ends open making the actual users more like
60. This database is 90 MB before compacting and 68 after. It hasn't
corrupted since we dumped a bad Dell Wireless setup about 20 months ago.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access Downloads
http://www.datastrat.com
http://www.mvps.org/access

 

['69 Camaro]

Hi, Arvin.

That really varies with the design of the database.

Agreed. There are a number of variables to consider, including the
complexity of the database design, the rate of database transactions, the
speed and load on the network, and the skills of the database developer. An
expert database developer can build a database application that serves 60
concurrent users comfortably, while a novice database developer can be given
the same network environment and system requirements, but build a database
application where one user is too many.

For the average database developer with common database applications -- I
can't really say that there's an average database application, because
database needs vary greatly from organization to organization -- 60
concurrent users in a 70 - 90 MB database is optimistic, but not out of the
question. The more "read-only" users that open the database, the more
concurrent users the database application can handle comfortably. The rate
of record inserts, updates and deletes that require record locks will
certainly cut down on the optimum number of users that can comfortably use a
given database application.

In general, someone who needs to ask, "How many concurrent users can log
into an Access database?" can expect to accommodate from five to 30 users
comfortably.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

['69 Camaro]

Hi, David.

I'm not aware of any specific security problems
with using an Access/Jet database on a web server.

I won't go into details because I don't want to give people ideas about how
to hack into a Web server, but users are allowed certain security
permissions in order to use an Access database, and the security risk lies
in what _else_ a user with malicious intent can do with these otherwise
innocuous security permissions.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[david epsom dot com dot au]

In a normal Web Server situation, 'users' aren't allowed
any permission at all - the web server itself is the only
login, and it has a special user name that it uses.

That web-server user name needs to have read permission
on file areas that hold the HTML files. It also needs to
have write permission on the file areas that hold the
jet mdb files if you plan to write to them.

This is analogous to the situation with SQL Server: a
common way of configuring SQL server is to give the web-
server user name read/write permissions into the SQL
Server database (instead of into the Jet MDB file folder),
if you plan to write to it.

In any case, you should not give permissions (on to the
file server, or on to the SQL Server) greater than those
required. And both SQL Server and Access/Jet allow
intrinsic access to mail systems, other database systems,
and to Windows, which should be blocked unless required.

Historically, the greater risk has been with SQL Server,
because it had more features, and has been harder to
administer and maintain.

However, when properly administered and maintained by a
qualified person, SQL Server provides acceptable security
and stability, better build in support for backup and update,
and the client processes are single threaded and thread
safe.

(david)

 

['69 Camaro]

Hi, David.

The minimal security permissions you describe are the only permissions a
knowledgeable hacker needs to create a great deal of mischief on a Web
server.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[david epsom dot com dot au]

The minimal security permissions you describe are the only permissions

a knowledgeable hacker needs to create a great deal of mischief on a
Web server.

Correct. History shows us that knowledgeable hackers have created a
great deal of mischief on Web Servers, particularly those attached to
SQL Server.

SQL Servers also tend to go down sporadically if maintenance plans
aren't in place, so from both a security and a stability point of
view, I wouldn't recommend SQL Server to anyone who couldn't already
at least handle file system security.


With internet servers, there is a problem if you enable file sharing:
since you shouldn't enable file sharing on a internet server, there
is a problem with backup and update of a jet/access database. This
and the thread problem are the two important reasons for considering
alternatives to Jet/Access data on a small web server.

On a large site you would also have to consider the problems of
clustering, locking, and transaction handling.

(david)

 

['69 Camaro]

Hi, David.

SQL Servers also tend to go down sporadically if maintenance plans
aren't in place, so from both a security and a stability point of
view, I wouldn't recommend SQL Server to anyone who couldn't already
at least handle file system security.

I would also add that a poorly designed stored procedure or trigger can
bring SQL Server to its knees, too.

On a large site you would also have to consider the problems of
clustering, locking, and transaction handling.

All in a day's work for a professional DBA. ;-)

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)