Part VI: Access as an Enterprise Platform
1194
Many client/server databases are written as three-tier systems. The data-management tier runs on
the database server computer, while the user interface is managed on the client-side workstation.
The business logic is often split between the client and server computers. Data validation, user
notification, and data transformation often take place within the user interface, usually in the pro-
gramming code under the forms and reports. The server computer may also implement business
logic in the form of user-defined functions and stored procedures that validate and verify data
before storing it in the database’s tables. Additionally, triggers in each table might apply certain
business rules or transformations at the lowest possible data level.Putting It All Together: Access,
Client-Server, and Multiple Tiers
Access is really a combination of an application development system, database development tools,
and a database engine. The target markets for Access as a database development system are work-
groups, small to medium businesses, and individual users.Most often, client-side applications that use server-provided data are built with tools like Visual
Studio .NET or the Java programming language. These development systems provide no database
capabilities themselves, yet they support all the features needed by client-side database applica-
tions. A relatively simple application written in Visual Basic .NET or Microsoft Access is able to
work with millions of records of data stored in SQL Server, without having to support all the data-
base operations supported by a server database engine.Now, just imagine a scenario with an Access database on a single desktop computer. Then add an
application or two, or maybe a dozen different applications, each one written in a different develop-
ment system (Access, VB.NET, Microsoft Excel, and so on). Then imagine a single Access .accdb
file trying to simultaneously service dozens, even hundreds of users. This is a prescription for disaster
because it’s really not the kind of environment best-suited for an Access .accdb database.Microsoft has never represented Access as a strong candidate for an application servicing large
numbers of simultaneous users. Instead, Microsoft has always primarily positioned Access as a sin-
gle-user or workgroup database system. Over time, of course, the capabilities built into Access
have improved to the point that Access is now a valid tool for building client-side applications that
hook into server-provided data. As mentioned earlier in this chapter and in Part V, Access seam-
lessly consumes data provided by SharePoint, no matter where that data is located. Similarly,
Access is also able to use data managed by Microsoft SQL Server or Oracle, located on the local
network or anywhere on the Internet.Access has severe limitations in client/server environments and, realistically, can’t be used to drive
an Internet site. Even in large-scale computer systems, however, a tool like Access plays an impor-
tant role as a front-end development tool for server data.