لطفا منتظر باشید ...
Using Access as a Front End
If you're planning to use Access as a front end to other databases, you need to consider a few issues. In fact, the whole design methodology of your system will differ depending on whether you plan to store your data in an Access database or on a back-end database server.In a system where you store your data solely in Access tables, the Jet Engine supplies all data retrieval and management functions and handles security, data validation, and enforcement of referential integrity.In a system where Access acts as a front end to client/server data, the server handles the data management functions. It's responsible for retrieving, protecting, and updating data on the back-end database server. In this scenario, the local copy of Access is responsible only for sending requests and getting either data or pointers to data back from the database server. If you're creating an application in which Access acts as a front end, capitalizing on the strengths of both Access and the server can be a challenging endeavor.
Things You Need to Worry About When Converting to Client/Server
The transition to client/server technology isn't always a smooth one. You need to consider the following factors if you're developing a client/server application or planning to eventually move your application from an Access database to a back-end structured query language (SQL) database server:
- Not every back-end database supports all field types that Access supports.
- The upsizing process will not convert any security you set up in Access to your back-end database.
- You will have to re-establish many of the validation rules you set up in Access on the back end.
- Not all back ends support referential integrity. Depending on the database that you are upsizing to, it is possible that the upsizing process might not automatically set up the referential integrity that you established in Access.
- Queries involving joins that could be updated in Access can't be updated on the back-end server.
This list is just an overview of what you need to think about when moving an application from an Access database with linked tables to a back-end server or when developing an application specifically for a back end. Many of these issues have far-reaching implications. For example, if you set up validation rules and validation text in your application, you will often need to rewrite the rules as triggers on the back end. If the user violates a validation rule that you set up on the back end, you will get a returnable error code. You have to respond to this code by using error handling in your application, displaying the appropriate message to your user. You can't use the Validation Text property with your client/server databases.TIPThe Access 2000, Access 2002, and Access 2003 Upsizing Wizards address most of the transitioning issues covered in this chapter. These tools, included as part of Access 2000, Access 2002, and Access 2003, respectively, automate the migration of data from the native Access data format to Microsoft SQL Server. Alison Balter's Mastering Access 2002 Enterprise Development covers the Upsizing Wizard.
Benefits and Costs of Client/Server Technology
With all the issues discussed in the previous section, you might ask, "Why bother with client/server?" In each case, you need to evaluate whether the benefits of client/server technology outweigh its costs. The major benefits include the following:
- Greater control over data integrity
- Increased control over data security
- Increased fault tolerance
- Reduced network traffic
- Improved performance
- Centralized control and management of data
These are some of the major expenses:
- Increased development costs
- Hardware costs for the server machine
- Setup costs for the server database
- The cost of employing a full- or part-time database administrator (DBA)
These and other issues are covered in more detail in Chapter 20.
Your Options When Using Access as a Front End
Client/server applications are not an all-or-none proposition, nor is there only one way to implement them through Access. One option is to use Access as a true front end, which means that you store all data on the server and process all queries on the server. You do this by using pass-through queries and stored procedures, rather than stored Access queries. With pass-through queries, you pass a back-endspecific SQL statement to the back end instead of allowing Access to process it. When you use stored procedures, you store SQL statements on the back end and then execute them using DAO or ADO code. (I cover both scenarios briefly in Chapter 20 and in detail in Alison Balter's Mastering Access 2002 Enterprise Development .)Chapter 20. I cover the ins and outs of working with ADP files in Alison Balter's Mastering Access 2002 Enterprise Development . In addition to the solutions just discussed, you can also download data to Access in bulk so that you can perform additional processing locally. Many possibilities exist, and each is appropriate in different situations. It takes experience and experimentation to determine the combination of methods that will optimize performance in a given situation.
What Are the Considerations for Migrating to a Client/Server Environment?
The preceding sections have given you an overview of the issues you need to consider when building a client/server application or considering moving to a client/server environment in the future. Chapter 20 provides more detailed information. If you're using Access as a front end, make sure that, as you read through this book, particularly the more advanced chapters, you take special note of any cautions about developing client/server applications. If you want in-depth coverage of client/server development techniques, refer to Alison Balter's Mastering Access 2002 Enterprise Development .
