لطفا منتظر باشید ...
What Types of Applications Can You Develop in Access?
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:
- Personal applications
- Small business applications
- Departmental applications
- Corporationwide applications
- As a front end for enterprisewide client/server applications
- Intranet/Internet applications
Access As a Development Platform for Personal Applications
At its most basic level, you can use Access to develop simple personal database-management systems. I caution people against this idea, though. People who buy Access hoping to automate everything from their wine collections to their home finances are often disappointed. The problem 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, data entry screens, reports, and the underlying tables that support them. In fact, when Microsoft first released Access, many people asked whether 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 of design and without writing a single line of code, most applications require at least some designing and custom code.As long as you're satisfied with a wizard-generated personal application with only minor modifications, no problems should occur. It's when you want to substantially customize a personal application that problems can happen.
Access As a Development Platform for Small Business Applications
Access is an excellent platform for developing an application that can run a small business. Its wizards let developers quickly and easily build the application's foundation. The ability to build code modules enables developers to create code libraries of reusable functions, and the ability to add code behind forms and reports enables 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 application in ways they can't accomplish on their own. Small business owners often experience this problem on an even greater scale. 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.
Access As a Development Platform for Departmental Applications
Access is perfect for developing applications for departments in large corporations. It's relatively easy to upgrade departmental users to the appropriate hardwarefor example, it's much easier to buy additional RAM for 15 users than it is for 4,000!Furthermore, Access's performance is adequate for most departmental applications without the need for client/server technology. Finally, most departments in large corporations have the development budgets to produce well-designed applications.Fortunately, most departments 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 they have contributed to the development of their application. It also makes my life as a developer much easier. I can focus on the hard-core development issues, leaving some of the form and report design tasks to the local talent.
Access As a Development Platform for Corporationwide Applications
Although Access might be best suited for departmental applications, you can also use it to produce applications that you distribute throughout the organization. How successful this endeavor is depends on the corporation. There's a limit to the number of users that 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 does the server have?
- How is the server already being used? For example, are applications such as Microsoft Office being loaded from the server or from local workstations?
- What types of tasks are the users of the application performing? Are they querying, entering data, running reports, and so on?
- Where are Access and your Access application 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 1015 concurrent users and more than 100,000 records. Remember, these numbers vary immensely depending on the factors mentioned, as well as on the definition of acceptable performance by you and your users. The basics of when to move to a client/server database are covered in Chapter 20, "Developing Multiuser and Enterprise Applications." I cover additional details about this topic in a separate book, Alison Balter's Mastering Access 11 Client/Server Development , also published by Sams.Developers often misunderstand what Access is and what it isn't when it comes to being a client/server database platform. People often ask me, "Isn't Access a 'client/server' database?" The answer is that Access is an unusual product because it's a file server application out of the box, but it can act as a front end to a client/server database. In case you're lost, here's an explanation: If you buy Access and develop an application that stores the data on a file server in an Access database, the workstation performs all data processing. This means that every time the user runs a query or report, the file server returns all the data to the workstation. The workstation machine then runs the query, and displays the results in a datasheet or on a report. This process generates a significant amount of network traffic, particularly if multiple users are running reports and queries at the same time on large Access tables. In fact, such operations can bring the entire network to a crawl.
Access as a Front End for Enterprisewide Client/Server Applications
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 that access client/server data directly.Chapter 20 briefly covers the alternatives and techniques for developing client/server applications. Alison Balter's Mastering Access 11 Client/Server Development provides details on how to develop Access projects.NOTEADPs were introduced in Access 2000. Many people considered them version 1.0 technology in that product. Microsoft did significant work with ADP files in Access 10. Today, they are a viable solution for client/server application development.When you reduce the volume of network traffic by moving the processing of queries to the back end, Access becomes a much more powerful development solution. It can handle huge volumes of data and a large number of concurrent users. The main issues usually faced by developers who want to deploy such a wide-scale Access application are the following:
- The variety of operating systems used by each user
- Difficulties with deployment
- The method by which each user is connected to the application and data
- The type of hardware each user has
Although processing of queries in a client/server application is done at the server, which significantly reduces network traffic, the application itself still must reside in the memory of each user's PC. This means that each client machine must be capable of running the appropriate operating system and the correct version of Access. Even when the correct operating system and version of Access are in place, your problems are not over. DLL (Dynamic Link Library) conflicts often result in difficult-to-diagnose errors and idiosyncrasies in an Access application. Furthermore, Access is not the best solution for disconnected users who must access an application and its data over the Internet. Finally, Access 11 is hardware hungry! The hardware requirements for an Access application are covered later in this chapter. The bottom line is that, before you decide to deploy a wide-scale Access application, you need to know the hardware and software configurations of all your system's users. You must also decide whether the desktop support required for the typical Access application is feasible given the number of people who will use the system that you are building.
Access As a Development Platform for Intranet/Internet Applications
Using data access pages, intranet and Internet users can update your application data from within a browser. Data access pages are HTML documents that are bound directly to data in a database. Although Access stores data access pages outside your database, you use them just like 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 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 your database objects as either static or dynamic HTML pages. Static pages are standard HTML 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 Page) file format. The Web server publishes HTX (HTML Extension)/IDC (Internet Database Connector) files dynamically, and they 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 10 introduced the capability to create 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.NOTEThis book provides some coverage of intranet and Internet development using Microsoft Access. Alison Balter's Mastering Access 11 Client/Server Development provides detailed coverage of intranet and Internet development using Microsoft Access.
