I often find myself explaining exactly what types of applications you can build with Microsoft Access. Access offers a variety of features for different database needs. You can use it to develop six general types of applications:
Front-end applications for enterprisewide client/server databases
At a basic level, you can use Access to develop simple personal database-management systems. I know people who automate everything from their wine collections to their home finances. The one thing to be careful of is that Access is deceptively easy to use. Its wonderful built-in wizards make Access look like a product that anyone can use. After answering a series of questions, you have finished application switchboards that allow you to easily navigate around the application, data-entry screens, and reports, as well as the underlying tables that support them. In fact, when Microsoft first released Access, many people asked if I was concerned that my business as a computer programmer and trainer would diminish because Access seemed to let absolutely anyone write a database application. Although it's true that you can produce the simplest of Access applications without any thought for design and without any customization, most applications require at least some design and customization.
If you're an end user and don't want to spend too much time learning the intricacies of Access, you'll be satisfied with Access as long as you're happy with a wizard-generated personal application. After reading this text, you can make minor modifications, and no problems should occur. It's when you want to substantially customize a personal application without the proper knowledge base that problems can happen.
Access is an excellent platform for developing an application that can run a small business. Its wizards let you quickly and easily build the application's foundation. The ability to build code modules allows power users and developers to create code libraries of reusable functions, and the ability to add code behind forms and reports allows them to create powerful custom forms and reports.
The main limitation of using Access for developing a custom small-business application is the time and money involved in the development process. Many people use Access wizards to begin the development process but find they need to customize their applications in ways they can't accomplish on their own. Small-business owners often experience this problem on an even greater scale than personal users. The demands of a small-business application are usually much higher than those of a personal application. Many doctors, attorneys, and other professionals have called me in after they reached a dead end in the development process. They're always dismayed at how much money it will cost to make their application usable. An example is a doctor who built a series of forms and reports to automate her office. All went well until it came time to produce patient billings, enter payments, and product receivable reports. Although at first glance these processes seem simple, upon further examination, the doctor realized that the wizard-produced reports and forms did not provide the sophistication necessary for her billing process. Unfortunately, the doctor did not have the time or programming skills to add the necessary features. So, in using Access as a tool to develop small-business applications, it is important that you be realistic about the time and money involved in developing anything but the simplest of applications.
Access is perfect for developing applications for departments in large corporations. Most departments in large corporations have the development budgets to produce well-designed applications.
Fortunately, most departments also usually have a PC guru who is more than happy to help design forms and reports. This gives the department a sense of ownership because it has contributed to the development of its application. If complex form or report design or coding is necessary, large corporations usually have on-site resources available that can provide the necessary assistance. If the support is not available within the corporation, most corporations are willing to outsource to obtain the necessary expertise.
Although Access might be best suited for departmental applications, you can also use it to produce applications that you distribute throughout an organization. How successful this endeavor is depends on the corporation. There's a limit to the number of users who can concurrently share an Access application while maintaining acceptable performance, and there's also a limit to the number of records that each table can contain without a significant performance drop. These numbers vary depending on factors such as the following:
How much traffic already exists on the network.
How much RAM and how many processors the server has.
How the server is already being used. For example, are applications such as Microsoft Office being loaded from the server or from local workstations?
What types of tasks the users of the application are performing. For example, are they querying, entering data, running reports, and so on?
Where Access and Access applications are run from (the server or the workstation).
What network operating system is in place.
My general rule of thumb for an Access application that's not client/server based is that poor performance generally results with more than 10?15 concurrent users and more than 100,000 records. Remember that these numbers vary immensely depending on the factors mentioned, as well as on the what you and the users define as acceptable performance. If you go beyond these limits, you should consider using Access as a front end to a client/server database such as Microsoft SQL Server?that is, you can use Access to create forms and reports while storing tables and possibly queries on the database server.
A client/server database, such as Microsoft SQL Server or Oracle, processes queries on the server machine and returns results to the workstation. The server software itself can't display data to the user, so this is where Access comes to the rescue. Acting as a front end, Access can display the data retrieved from the database server in reports, datasheets, or forms. If the user updates the data in an Access form, the workstation sends the update to the back-end database. You can accomplish this process either by linking to these external databases so that they appear to both you and the user as Access tables or by using techniques to access client/server data directly.
Alison Balter's Mastering Access 2002 Enterprise Development, published by Sams, covers the details of developing client/server applications with Microsoft Access.
By using data access pages, intranet and Internet users can update application data from within a browser. Data access pages are Hypertext Markup Language (HTML) documents that are bound directly to data in a database. Although Access stores data access pages outside a database, you use them just as you do standard Access forms except that Microsoft designed them to run in Microsoft Internet Explorer 5.5 or higher, rather than in Microsoft Access. Data access pages use dynamic HTML in order to accomplish their work. Because they are supported only in Internet Explorer 5.5 or higher, data access pages are much more appropriate as an intranet solution than as an Internet solution.
In addition to using data access pages, you can also publish database objects as either static or dynamic HTML pages. Static HTML pages are standard HTML pages that you can view in any browser. You can publish database objects either dynamically to the HTX/IDC file format or to the ASP (Active Server Pages) file format. Dynamically means that these pages are published by the Web server each time that they are rendered. The Web server publishes HTX/IDC files dynamically, and these files are therefore browser independent. The Web Server also dynamically publishes ASP files published by Microsoft Access, but the published ASP pages require Internet Explorer 4.0 or higher on the client machine.
Access 2002 introduced the ability to create Extensible Markup Language (XML) data and schema documents from Jet or SQL Server structures and data. You can also import data and data structures into Access from XML documents. You can accomplish this either using code or via the user interface.