MS Access is a large application, and deployment can be tricky. If
you can, make sure that they already have Access installed. If you
can't, make sure that the deployment of Access is the responsibility
of the IT desktop support people - not the database developer.

Well, you've tried it with 150 users, but Access Linked Tables are
not really optimised for client/server: Do you mean you have linked
tables, or do you mean only that you are using ODBC with ADO?

Linked Tables in an Access Front End means that you are going through
a Jet Translation layer (still single user, entirely on the workstation)
before you get to the ODBC layer.  The Jet layer is slow, handles stored
procedures inflexibly, and handles transactions badly. The net effect
is that sometimes you have to work a little harder on your FE design.

Having said that, the only thing I would worry about is locking, and
if you've designed a system that doesn't accidentally assert table locks
with 2 users, there is no reason to expect a problem with 600.

Your Access users are all single users. Their only connection to
the database is via ODBC.  Is there something inherent in ODBC
connections to the Server that will prevent you from having 500
users?  You should ask in a Server group.

(david)

Mike, I've not worked on anything with quite so large a user audience, but
my experiences with Access-Jet-ODBC-server have been satisfactory with
audiences up to about 200, some connecting over moderately slow links in a
LAN.

The prime contractor on that largest C/S project found it best to obtain and
use a third-party installation program -- the one he chose was Wise. We did
not, however, as some suggest, use the SageKey scripts. A colleague on the
project became very expert with Wise scripting language -- the client had an
enormous corporate license for the version of Access we were using and most
users had moved on to a later version so the install script installed full
Access, the application, and a third-party graphics package on each user's
desktop.

I don't know david epsom's criteria for the Jet layer being slow, but, in
our case, the users and client felt that performance was more than adequate.

We had only a few stored procedures -- the client and prime contractor had
agreed because it was far easier to find and hire competent Access people
than to find and hire competent server DB people (it was more difficult
because the server was Informix and there aren't nearly as many Informix
folk available as SQL Server types) and no transactions. The stored
procedures that we had were simply to get around the problem of using
AutoNumber-equivalents in a server and returned just one number, the "next
unique id" for a particular table -- there was never a problem with them.

In addition, to avoid the occasional "too complex query" that would bring
oodles and gobs of data back for Jet to process, we had a few (and few is
the operative word) Informix Views defined.

The scenario that david describes for using ADO, with disconnected
recordsets, would seem to preclude locking and one "line of defense" at the
DB engine level -- that alone would cause me concern. In fact, we've seen
reports in various newsgroups indicating that in some | many situations
Jet-ODBC-server actually outperforms ADO-server; it was anecdotal evidence,
to be sure, but the hype for ADO was so intense that I was happy to see
someone dealing with reality.

 Larry Linson
 Microsoft Access MVP

Sounds like your asking for trouble.  Not only do you need to deploy your application once - but every time you change the front end due to a bug fix or enhancement you'll need to deploy the entire front end to every single user all over again.