Multi user VB6 Access Backend Database

[ChrisM]

Hi,

I have a VB6 application which has to use an MS Access database as a back
end.

I'm not really used to using Access as a back-end. Usually use SQL Server.

Anyway,
I have split the back-end Access into 2 parts, all the data: 'Tables
Database', and the queries: 'Queries Database'

If I want to make this multi-user, obviously the 'Tables Database' will
reside on the server, but should each user have their own copy of the
'Queries Database' on their PC, as well as a copy of my application, or can
each copy of the application refer to one instance of the 'Queries Database'
(ie a copy on the server).

Thanks,

ChrisM

 

[Richard T. Edwards]

Be afraid. Be very afraid!!!!!!!!!!!!!!!!!!!!!!!!!!11

First, issue supreme. Multiusers opening up an access database at the same
time is bad, bad, bad.

 

[Larry Linson]

Be afraid. Be very afraid!!!!!!!!!!!!!!!!!!!!!!!!!!11

First, issue supreme. Multiusers opening up an access database at the same
time is bad, bad, bad.

 

[Larry Linson]

Be afraid. Be very afraid!!!!!!!!!!!!!!!!!!!!!!!!!!11

First, issue supreme. Multiusers opening up an
access database at the same time is bad, bad, bad.

Perhaps your experience differs from the vast majority. The fact that it is
commonplace to have multiple users concurrently accessing Jet (Access is, in
fact, the UI and development tool for Jet and other DB engines) is why there
is this newsgroup, microsoft.public.access.multiuser.

It deals, more often, with multiple users of Access sharing datatables in a
Jet database, but the issues are similar with a VB front end. But, just for
the record, if all the factors are near-perfect, we have a number of
reliable reports of 100+ concurrent users on a shared Jet backend, with
acceptable performance.

It is certainly NOT a "be afraid", scenario.

On the other hand, with all factors just about as far from perfect as one
could imagine, especially design, it is possible to have unacceptable
performance with just a handful, or even one, user.

And, in a well-designed multiuser environment, similar to the one that the
original poster described, each user has their own copy of the front-end and
is linked to the tables in the Jet backend, so strictly speaking, you do not
HAVE "multiple users OPENING an Access database". It is true that multiple
users logged in to the same copy of a front-end or monolithic database can
signifcantly increase the chances of corruption, but that is not what was
described, and, in fact, it often works without problems for a long, long
time.

There's an introductory presentation on Access in a Multiuser Environment
that I did for my user group that you can download from
http://appdevissues.tripod.com. It will identify topics that I thought
worthwhile to discuss, and a bit more. The best collection of detailed
information and links on the subject of Access in the multiuser environment
is at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm.

Take a look at these, and post back here if you have more questions.

Larry Linson
Microsoft Access MVP

 

[Jezebel]

That answer rather begs the question, it seems to me. The challenge with
Access is that 'all factors near perfect' is much harder to achieve then
with other multi-user database products. I've *heard* that there are
multi-user access systems that work well; but I've never *seen* one. And I
have seen quite a few Access systems: they were all dogs. Truly. ALL of
them.

Even you talk only of 'reliable reports' -- so it sounds like you've never
actually seen one either. Don't get me wrong, I'm not doubting you and I
don't suggest for a moment that it can't be done well. But in practice,
success is very rare. Perhaps you've never worked at the coalface of
corporate IT: believe me, there is much to be afraid of. They used to say
nobody ever got fired for choosing IBM: the reverse is true of Access.

 

[Tony Toews]

That answer rather begs the question, it seems to me. The challenge with
Access is that 'all factors near perfect' is much harder to achieve then
with other multi-user database products. I've *heard* that there are
multi-user access systems that work well; but I've never *seen* one. And I
have seen quite a few Access systems: they were all dogs. Truly. ALL of
them.

Client is running such. 20-25 users all day long. Some in A97, some
in A2000. Some on Citrix/Terminal server. Backend has 150 tables.
Some tables with 400K records and is 300 Mb in size.

Even you talk only of 'reliable reports' -- so it sounds like you've never
actually seen one either. Don't get me wrong, I'm not doubting you and I
don't suggest for a moment that it can't be done well. But in practice,
success is very rare.

Respectfully a smoothly running MDB is common place. Sure there are
corruptions but they are usually easily repaired and the problem
usually located. Not always of course.

Hmm, now that I think about it I don't recall seeing any postings
asking about corruption who have posted back saying that nothing
solved their problem. Of course they could be rather frustrated.

Perhaps you've never worked at the coalface of
corporate IT: believe me, there is much to be afraid of. They used to say
nobody ever got fired for choosing IBM: the reverse is true of Access.

That's because of the bad image that Access has among the university
degree types who think badly of the Access databases created by the
secretary and management types. But then they're likely desperate
for solutions because the IT department is working on the "perfect"
solution involving 3-tiered practices, SQL Server and ASP.NET. Or VB.
Or whatever else.. And which will happen to cost 10 times as much as
what an experienced, quality Access database person can create. And
only do 70% of what the client really needs.

Am I being deliberately obnoxious? A little bit. <smile>

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

 

[Jezebel]

Not obnoxious (apart from the reference to 'university types' which is
gratuitous, irrelevant, and at least in this instance quite wrong also.
Maybe you've just been lucky. (Or maybe I've just been unlucky!) Of course
there are plenty of smooth mdb's running in small set-ups. The beef is
specifically with multi-user network set-ups with enough traffic to matter,
examples of success with which are few and far between. (But, as I said, not
unheard of -- if yours is one of the rare successes, good luck to you.)

In all the cases I've seen the development savings achieved by developing in
Access were chewed up *many* times over by the maintenance costs and
subsequent write-off when the orgs involved finally gave up.

 

[Arvin Meyer]

Not obnoxious (apart from the reference to 'university types' which is
gratuitous, irrelevant, and at least in this instance quite wrong also.
Maybe you've just been lucky. (Or maybe I've just been unlucky!) Of course
there are plenty of smooth mdb's running in small set-ups. The beef is
specifically with multi-user network set-ups with enough traffic to matter,
examples of success with which are few and far between. (But, as I said, not
unheard of -- if yours is one of the rare successes, good luck to you.)

In all the cases I've seen the development savings achieved by developing in
Access were chewed up *many* times over by the maintenance costs and
subsequent write-off when the orgs involved finally gave up.

My own experience is contrary to yours. I inherited a rather poorly designed
Jet database table set with a well coded (good VB programmer but poor
database designer) Access front-end. In the 4 years that I've maintained it,
the only corruption was a series of hardware corruptions due to a bad
wireless access connection. The database is in hard daily use and has 36
concurrent users in 10 different Access front-ends 6 to 7 active users with
asp front-ends and data also being written occasionally through Exchange
Event Services to one table. One user can put as many as 8,000 rows in the
database in a single 45 minute session. Right now it compacts to 62 MB and
shows no problems with corruption since the hardware has been fixed over a
year ago.

I have dozens of other examples with user counts ranging from 4 or 5 to 50,
with the average being in the 15 to 20 range. On the 50 user database there
are 35 active users and 15 terminal serving from 2 different cities through
VPN connections. The largest application I've heard of was a 200 user Access
app run by Steven Drinovsky at the Texas Department of Health. The app was
mostly read-only so I'd not include it with the others that are actively
used for data entry.

I have a hard time understanding the corruption reports since every instance
I've ever seen can be directly traced to user error (turning off a machine)
or a bad piece of hardware. I've only personally seen a few corruptions in
the 11+ years I've been an Access developer. Once I fix the first database I
mentioned, I figure it will reduce to about 45MB and last at least another 5
years before I move it to SQL-Server.

Speaking of corruption, the worst I've ever experienced was not with Jet,
but with SQL-Server. It is the only corruption I've ever experienced where
the entire database was lost and needed to be restored from backup and the
log used to recapture the last day's data. It also took the longest to
repair (4.5 hours) of any that I've had to fix. I have an Access 2.0
database that has never corrupted and has been running since the fall of
1997. I have several Access 97 databases that started as Access 2.0 and have
only had 1 or 2 corruptions in over 8 years or use. I've seen more corrupted
Word files than I've seen corrupted Access files. I'd have to believe that
you are just unlucky.

Speaking of maintenance costs, ASP applications are 10 to 12 times as
expensive to maintain as Access front-ends and about twice as expensive as
VB fron-ends. At the data end, the cheapest of the major Microsoft apps I've
seen is Access, followed by FoxPro, then SQL-Server, with the most expensive
being Exchange (also a type of Jet engine). The overall most expensive
engine I've ever seen to either build with or maintain is a tossup between
Exchange and Oracle. Oracle becomes more expensive considering the cost of
the time, and Exchange cost more to fix considering the amount of time.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Albert D. Kallal]

The beef is
specifically with multi-user network set-ups with enough traffic to matter,
examples of success with which are few and far between. (But, as I said, not
unheard of -- if yours is one of the rare successes, good luck to you.)

The above is a very fair question. We would most certainly have to spend a
bit of time defined what you mean by enough traffic?

A very large portion of business applications really don't have that much
data. I have a good number of clients using access applications of mine.
They have these applications for years without trouble. (in fact, no ONE a97
corruption yet!). Of course, most of these example clients of mine are about
only a 5 user systems. The tables sizes are small, usually only in the
40,000 record range. The application would be considered medium size by
access standards. It has 160 forms, 25,000 lines of access VB code, and 60
tables. As a note, the development language in ms-access is the same as VB,
but a different forms model. Most of these applications even use class
objects that I wrote in ms-access.

That above application with 5 users responds instantly under all situations
I can think of for that client. I mean, really...5 users and those small
tables is nothing for JET. On the other hand, the above type of business
application represents a VERY large swath of what the typical small business
multi user database looks like.

Further, the above company can run for a good year or more without any
database admin, or any special setup on the server side. It really is free
for the client to run. There is no cost of running and setting up and
maintain sql server. Who is going to pay for that? Of course, if one is in
the IT business...you don't want to sell something that don't take expensive
help to run ...right? Hence, the general dis-like of JET..since it is too
low cost!

I should mention that in fact the majority of my clients are in the above
size in terms of users and data size. They all experience first rate
performance, and have virtually no maintenance costs as a result of running
my software. I mean, really, why run sql server with 5 or 10 users, and 50
tables that are only each in the 40,000 record range? It is silly!

As mentioned, most IT people would want YOU to use sql server, as it
generates a good support flow of dollars. You might as well jump on this
wagon, as most of these folks will do everything possible to make you NOT
use ms-access.

And, yes...I will most certainly agree that if your tables sizes are in the
millions, and your user count is 30 users, then yes, I have to agree with
you. That kind of table size and those kinds of user numbers warrants that
you use a server based system in place of a file share mdb and JET.

The real beauty of ms-access is that you can switch the back end data store
to sql server anyway.

In fact, you can even develop native OLEdb sql server applications with
ms-access if you wish (that is no local tables...and a 100% OLEdb connection
to sql server). With this setup, there are some systems with a user count in
the 1000's.

Further, the last 3 versions of ms-access have shipped with a true client to
server based engine anyway (the MSDE). This free engine included on the
office cd is 100% compatible with sql server. Ms-access is now designed to
work with, and be a front end to sql server right out of the box. Hence, as
access developers...we have a lot of choices here!

In all the cases I've seen the development savings achieved by developing in
Access were chewed up *many* times over by the maintenance costs and
subsequent write-off when the orgs involved finally gave up.

Lets not confuse the data engine with the product ms-access. Ms-access is
not really a database, but only a visual basic development tool. It can
easily be the front end for JET, or Sql server, or Oracle..or whatever. So,
ms-access is only a "access" or a client tool to develop applications with.

As for poor results? Hum, I seem way more disasters with using VB to sql
server then I seen with ms-access. And, those horrible results usually
entail much larger disasters from a budget point of view!

Also, poorly written VB to sql applications tend to have the worst UI. In
fact, the last VB to sql system I did a consult on was a real mess. That
consult was either to dump the $400,000 they had spent on a VB to sql server
system or to keep it. Wow, what a mess and even things like Referential
Integrity was NOT used. (it was all in the code!).

So, good VB programmers don't write good database applications either.
However, good database developers tend to write far better applications when
what you see with c++ or VB to sql server applications written by strong
coders...but weak database skills.

So, Cleary, there is wide differing in your experiences compared to my
travels in the IT world.

At the end of the day...it all comes down to having good designs and
developers on the project. Without good developers...then one can make a
huge mess with any platform..and that includes ms-access.

 

[ChrisM]

It's interesting to read about everyones experiences, it would seem that on
balance it should work OK (If I'm lucky?!).
No-one has actually answered my original question yet, although by reading
between the lines, I sounds as if I should go for the MDB containing the
tables on the server, and a copy of the MDB containg the queries on each
machine that will be running the software.
Could someone please confirm that this is the best way to go.

Thanks,

ChrisM

 

[Albert D. Kallal]

Actually, the responses are interesting.

My bets for your setup? Yes, put the copy of the queries on each station
just like you do with the application. It will be more reliable and use
somewhat less bandwidth as that mdb file don't cross the network. Yes..this
is the way to go.

If you like most access developers have some "auto update" routine that at
start-up checks for a new version of your software and grabs it from the
server..then just include the copying of the new mdb file with the possible
new updated queries also in that process.

 

[Jezebel]

I guess you need to hope that some of these posters who have experience with
Access working well can answer your question. Seems to me that their
responses are a trifle slippery on facts, more concerned with justification
than emprical argument; but I'm a cynical shit at the best of times. (And
after a lot of years in the IT industry, I have long stopped stopped getting
any enjoyment from saying "I told you it wouldn't work" at the
post-catastrophe conference.)

 

[Larry Linson]

That answer rather begs the question,
it seems to me. The challenge with
Access is that 'all factors near perfect'
is much harder to achieve then with
other multi-user database products.

What you state as though it were fact has not been my experience. Certainly
"all factors" includes the application requirements, and, as one of my
corporate colleagues said, on a different software topic, "You've gotta know
what you're doing."

One difference is that you rarely see an SQL Server, or Oracle database that
was developed by an amateur. And, of course most other "multi-user database
products" are, in fact, high-powered, and high-priced server databases. The
Corporate IT staff won't let an amateur developer _near_ them, in most
cases.

I've *heard* that there are multi-user access
systems that work well; but I've never *seen*
one. And I have seen quite a few Access systems:
they were all dogs. Truly. ALL of them.

Someone, then, has had to go to great lengths to foul up the ones you've
seen, because that's what it takes to make an Access application into a
"dog".

Even you talk only of 'reliable reports' --
so it sounds like you've never actually
seen one either.

I've only seen one Jet database application with over 100 users -- done by a
personal friend, Drew Wutka, for his employer, using VB not Access. But he
doesn't put it in exactly the multiuser category, because the UI and the
back end are both interfaced by VB -- he says that he has turned it into a
true client-server environment (and I agree).

The "reliable reports" come from people whose honesty, technical ability,
and integrity I trust. A few of them are Michael Kaplan, a former MVP now a
Microsoft employee; Stephen Forte, a well-known author, consultant, and
developer; and Michael Groh, Tech Editor of _Access, VB, and SQL Advisor_.

I cheerfully admit that my personal development of multiuser applications
has topped out in the mere teens and twenties of users, but I have observed
others happily and adequately supporting from 30 to 70 users, on a routine
basis. And, that range of audience size is reported so frequently in Access
newsgroups that you'd have to think much of the user community were liars if
it were all braggadocio.

Don't get me wrong, I'm not doubting
you and I don't suggest for a moment that it
can't be done well. But in practice, success
is very rare.

Thanks for the kind words. In fact, it not only _can_, but often _is_, done
well. And in my observation, success is not at all rare. I have led an
Access user group since early 1993, and all but a smidgin of the paying work
I've done since 1993 has been in Access -- standalone DBs, multiuser DBs,
but, mostly, Access as a client to SQL Server, Informix, and various Sybase
products. Because I am an independent consultant, I have had the opportunity
to see, up close, quite a lot of different databases, as well as those of
members of my user group and another Access Developer's group of which I am
a member.

Perhaps you've never worked at the coalface
of corporate IT:

In the early 1990s, I retired from IBM after 26 years, half of which had
been in their contract services organization, developing software and
consulting for their customers. Following that, I did some independent
consulting on mainframes and some VB until Access was released, at which
point my VB work fell to a far second-place and almost all my work was
Access-related. The majority of the Access contract work that I have done is
for Fortune 500 clients. Would that qualify as "close to the coalface"?

believe me, there is much to be afraid of.
They used to say nobody ever got fired for
choosing IBM: the reverse is true of Access.

Strange that, having direct experience in both situations, I can offer that
both are erroneous statements. As an IBMer, I have (to my chagrin) observed
people being fired for choosing IBM (back in the 'good old days') and, as an
Access developer/consultant, I have never seen anyone even reprimanded, much
less fired, for choosing Access.

I'll just have to say again, as my colleague was prone to say, "You've gotta
know what you're doing.", no matter what your software tool of choice. The
chances of a server DB developer or DBA having at least some training is
higher because IT management folk are likely to demand such qualifications
if the person is allowed to work on the corporate server database. But,
there are plenty of professional Access developers around who do quality
work, have never produced a "dog", and I am often amazed at the high quality
of databases produced with Access by people for whom database development is
not remotely their primary responsibility.

Larry Linson
Microsoft Access MVP

 

[Albert D. Kallal]

I guess you need to hope that some of these posters who have experience with
Access working well can answer your question.

That is fair, since it is quite clear you don't have much knowledge about
ms-access as a product.

Seems to me that their
responses are a trifle slippery on facts, more concerned with justification
than emprical argument

Actually, it seems that while you supposedly have some experience in the IT
industry, you seem to understand little, or what ms-access is. It is not a
question of being slippery..but just one of product knowledge. As mentioned,
access is only a client tool to your database engine of choice anyway.
Maybe, perhaps you don't understand client to server? When writing a two
tiered applications, ms-access is as scalable as any other development tool
in the market place. Be it VB, c++ or .net. The issue of scalability is
going to be that of what data engine you choose...and not ms-access.

; but I'm a cynical shit at the best of times. (And
after a lot of years in the IT industry, I have long stopped stopped getting
any enjoyment from saying "I told you it wouldn't work" at the
post-catastrophe conference.)

You have also seemed to lost the enjoyment of learning also. It would seem
that your views of ms-access are that of a viewpoint through a narrow straw.
The question is not one of being careful, and cynical...but at what point
you stopped learning about the product you know little about. You have just
stopped learning about this industry..and that seems very sad to me.

As for the JET engine? (which you can choose to use with ms-access, or not),
that engine is likely by far an away the most popular data engine in the
marketplace today. However, you do still seem to be confused on the issue of
ms-access, and the choice(s) of the data engines that developers now have.
You *REALLY* need to keep that in mind.

However, that JET engine still does thrive in the market place

Many Popular products have used the JET engine.

Some are:

Ms-access (now, as mentioned you don't have to use JET)
Windows NT (directory services)
Microsoft Money
Internet Information Server
Index Server
Microsoft Project.
A Jet variation even serves as the message store for Exchange Server.

Simply Accounting - a very popular accounting system, and is multi
user
CityDesk - a popular web contact management system

The above list is only a small sample (from memory!). However, I just want
to stress that you want to learn and distinguish between the data engine of
choice..and that of ms-access which is a client development tool.

You also should realize that for the last 3 versions of office there has
shipped a 100% compatible client to server sql engine for use with ms-access
(and it DOES NOT require JET). You should also note that the ms-access
developer tools are now part of Visual Studio office extensions (again..you
likely did not know this).

You obviously have some learning here to do...as it is clear ms-access is
not the product you once thought it was...

 

[david epsom dot com dot au]

I don't get Access work from people who are happy with the Server
and unhappy with Access. I do get Access work from people who are
happy with Access and unhappy with the Server.

Oddly enough, some of the Client-Server apps we have had to deal with
professionally have been badly designed resource hogs needing gigabytes
of memory to support half a dozen users, and totally unsuitable for
extension to a larger client base.

Of course I know enough to realise that they are that way because
the applications are badly designed by ignorant & under-resourced
development teams, but I'm afraid it biases my idea about the
typical mid-range development effort.

Typically I've seen the putative benefits of scalability and reliability
lost in a slow and unresponsive database running on $20K-$200K worth
of hardware after spending many times that in development costs -
and a management team with no option but to continue with product
they are stuck with.

In contrast, none of our Access applications have been that unpopular.
But due to market overlap some of our customers consider other suppliers,
and we do point out to those people that if they want to write off our
primary product after 6 months, the total cost (we sell at $20K to $200K)
will have been less than the maintenance contract on our upmarket
competitors....

(david)

 

[david epsom dot com dot au]

between the lines, I sounds as if I should go for the MDB containing the

tables on the server, and a copy of the MDB containing the queries on each

1) SQL in a local file.
2) SQL in the target database (like SQL Server)
3) SQL in a shared file

Think of the SQL as being a kind of data, stored in a database.

Data can be stored locally or shared, and may be in the same
database as the target database, or in an independent database.

If the SQL is STATIC, or tightly bound to the APPLICATION,
it makes sense to have a local copy.

If the SQL is tightly bound to the DATA, it makes sense to
include it in the target database. If you consider the metadata
(the structure of the database) as a kind of data, it would
make sense to include SQL if it depended on the metadata.
For example, you might ship data with a varying table structure,
but always include a static interface (view) in the database
file.

If the SQL is subject to frequent change, but independent
of the APPLICATION and DATA, a shared file would be appropriate.
For example, if you were using this file to switch between
different datasources during the day, you would use a shared
file rather than a local file.

As with any kind of code or data, you may decide to partition
the SQL between the three locations. You might put a few
queries in the target database, a few in a shared database,
and a few in a local database.

Or you might decide that there are logical imperatives that
over-ride the database design. If you are planning to move
to SQL Server, you might put all of your queries in the target
database as a first step: or you might just need to get rid of
the extra file. If you have done your development in Access,
all the queries might be in a local database to start with,
and you might never get around to moving them out when you
switch to VB. And of course you might decide that splitting
your SQL into three locations was just a truly stupid idea,
even if it did match your problem domain......

(david)

 

[Unicorn]

[SNIP] But, just for

the record, if all the factors are near-perfect, we have a number of
reliable reports of 100+ concurrent users on a shared Jet backend, with
acceptable performance.

Larry, F.Y.I., I think that the largest install that I am aware of with a
JET database is using the Who-Is-In software, ( www.hudsoft.com.au ) I
have been told that it is regularly installed on 2000 workstations in a very
large multinational software conglomerate starting with M.

Greg has done some rather interesting things with connections, but he
asserts that the 255 user limit presents him with no problems at all,
either performance wise or connection wise. He suggests, that the practical
limit for him is somewhere round 65,000 users.

Matt

 

[Unicorn]

[Snip]
It will be more reliable and use

somewhat less bandwidth as that mdb file don't cross the network. Yes..this
is the way to go.

I didn't think the entire MDB file was dragged across the network. Just the
whole tables required for SQL to manipulate.

In the case of queries, I thought it was just the query definition was
returned, until the query was actually executed.

If I am wrong, please jump all over me, cause I have made some major
blunders in the past, I am more than capable of having this wrong.

(Do you know what happens to a busy local network when 5 users try and check
for a files status every 10th of a second. I had my own DOS internally,
because of a simple algebraic error. )


Matt

 

[Larry Linson]

Perhaps, like my colleague Drew Wutka, he has used WinSock to communicate
from VB front ends to a VB interface to the back end, in effect, turning the
Jet database into a "client-server" configuration. Drew had nearly 300 users
at one time, but only a few would be actually communicating with the
"server" Jet database at any given time.

Larry Linson
Microsoft Access MVP

[SNIP] But, just for

the record, if all the factors are near-perfect, we have a number of
reliable reports of 100+ concurrent users on a shared Jet backend, with
acceptable performance.

Larry, F.Y.I., I think that the largest install that I am aware of with a
JET database is using the Who-Is-In software, ( www.hudsoft.com.au ) I
have been told that it is regularly installed on 2000 workstations in a very
large multinational software conglomerate starting with M.

Greg has done some rather interesting things with connections, but he
asserts that the 255 user limit presents him with no problems at all,
either performance wise or connection wise. He suggests, that the practical
limit for him is somewhere round 65,000 users.

Matt

 

[david epsom dot com dot au]

Perhaps, like my colleague Drew Wutka,

he has used WinSock to communicate

Possibly, but note that it is not a transactional application,
and at first glance it would appear that users only update
their own record. If the rest of the data access is read-only,
the application could be using local DAO and still only be
limited by the number of user licenses on the file server.

(david)

Perhaps, like my colleague Drew Wutka, he has used WinSock to communicate
from VB front ends to a VB interface to the back end, in effect, turning the
Jet database into a "client-server" configuration. Drew had nearly 300 users
at one time, but only a few would be actually communicating with the
"server" Jet database at any given time.

Larry Linson
Microsoft Access MVP

[SNIP] But, just for

the record, if all the factors are near-perfect, we have a number of
reliable reports of 100+ concurrent users on a shared Jet backend, with
acceptable performance.

Larry, F.Y.I., I think that the largest install that I am aware of with a
JET database is using the Who-Is-In software, ( www.hudsoft.com.au ) I
have been told that it is regularly installed on 2000 workstations in a very
large multinational software conglomerate starting with M.

Greg has done some rather interesting things with connections, but he
asserts that the 255 user limit presents him with no problems at all,
either performance wise or connection wise. He suggests, that the practical
limit for him is somewhere round 65,000 users.

Matt