S
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rebecca Riordan
It applies to any database server. You have to move as much processing as
possible onto the server in order to see any benefit. I've heard it said,
in fact, that performance may even degrade slightly if all you do is link to
SQL Server, but I've never tested that.
HTH
--
Rebecca Riordan, MVP
Designing Relational Database Systems
Microsoft SQL Server 2000 Programming Step by Step
Microsoft ADO.NET Step by Step
http://www.microsoft.com/mspress
Blessed are they who can laugh at themselves,
for they shall never cease to be amused...
possible onto the server in order to see any benefit. I've heard it said,
in fact, that performance may even degrade slightly if all you do is link to
SQL Server, but I've never tested that.
HTH
--
Rebecca Riordan, MVP
Designing Relational Database Systems
Microsoft SQL Server 2000 Programming Step by Step
Microsoft ADO.NET Step by Step
http://www.microsoft.com/mspress
Blessed are they who can laugh at themselves,
for they shall never cease to be amused...
L
Larry Linson
Something over half my work for the last ten years has been on Access client
applications with Jet, using tables linked via ODBC to various servers. But
I can't answer your specific question: we never escalated to client-server
from multiuser because of performance and user audience and there are too
many variables in the design and implementation of a database for there to
be any hard-and-fast rules. The largest client-server applications I worked
on had user audiences in the low hundreds.
I'm not certain why some here have become so "bashful" about the number of
users that a well-done multiuser Access-Jet database will support. There are
a number of factors, including the database application's requirements,
design, and implementation; and the hardware, software, and network
environments. If all are near-perfect, we've had reliable reports of
multiuser Access supporting 100+ users (and my guess is that the
requirements of those apps were such that most of the users were just
viewing/printing data) but we've routinely seen reports of people supporting
30 -70 users when not all the factors were near-perfect and with a mix of
view and update.
A well-designed, well-implented single-user standalone database, after
running the Splitter and linking the tables, is not necessarily a
well-designed, well-implemented multiuser database. Neither, with minimal
changes to link via ODBC to a server, is likely to be a well-designed,
well-implemented client-server application. But it is possible (and not to
difficult when you know what your goal is) to create a well-designed,
well-implemented Access database for each of these environments. And, I'll
have to add, you may be surprised at how robust and solid a well-designed,
well-implemented Access database can be in each environment.
It's an impressive and surprising "little desktop database".
For some topics I thought worthwhile discussing with my user group, download
the presentations on multiuser and ODBC client from
http://appdevissues.tripod.com/downloads.htm.
Larry Linson
Microsoft Access MVP
applications with Jet, using tables linked via ODBC to various servers. But
I can't answer your specific question: we never escalated to client-server
from multiuser because of performance and user audience and there are too
many variables in the design and implementation of a database for there to
be any hard-and-fast rules. The largest client-server applications I worked
on had user audiences in the low hundreds.
I'm not certain why some here have become so "bashful" about the number of
users that a well-done multiuser Access-Jet database will support. There are
a number of factors, including the database application's requirements,
design, and implementation; and the hardware, software, and network
environments. If all are near-perfect, we've had reliable reports of
multiuser Access supporting 100+ users (and my guess is that the
requirements of those apps were such that most of the users were just
viewing/printing data) but we've routinely seen reports of people supporting
30 -70 users when not all the factors were near-perfect and with a mix of
view and update.
A well-designed, well-implented single-user standalone database, after
running the Splitter and linking the tables, is not necessarily a
well-designed, well-implemented multiuser database. Neither, with minimal
changes to link via ODBC to a server, is likely to be a well-designed,
well-implemented client-server application. But it is possible (and not to
difficult when you know what your goal is) to create a well-designed,
well-implemented Access database for each of these environments. And, I'll
have to add, you may be surprised at how robust and solid a well-designed,
well-implemented Access database can be in each environment.
It's an impressive and surprising "little desktop database".
For some topics I thought worthwhile discussing with my user group, download
the presentations on multiuser and ODBC client from
http://appdevissues.tripod.com/downloads.htm.
Larry Linson
Microsoft Access MVP