- Why This Chapter Is Important
- Understanding the Client/Server Model
- Deciding Whether to Use the Client/Server Model
- The Roles Access Plays in the Application Design Model
- Learning the Client/Server Buzzwords
- Upsizing: What to Worry About
- Proactively Preparing for Upsizing
- Using the Upsizing Wizard
- Defining an ODBC Data Source
- Connecting to a Database Server
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Upsizing: What to Worry About
Suppose that your database is using Microsoft Access as both the front end and the back end. Although an Access database on a file server might have been sufficient for a while, the need for better performance, enhanced security, or one of the other benefits that a back-end database provides compels your company (or your client's company) to upsize to a client/server architecture. You have already created the Access tables. Those tables may even contain volumes of data. In this scenario, it might make sense to upsize.
Because you designed all the tables as Access tables, they must be upsized to the back-end database server. Upsizing involves moving tables from a local Access database (or from any PC database) to a back-end database server that usually runs on Unix, Windows 2000, Windows NT Server, and OS/2 LAN Server or as a Novell NetWare NLM.
Another reason why tables are upsized from Access to a back-end server is that many developers prefer to design their tables from within the Access environment. Access offers a more user-friendly environment for table creation than most server applications.
Because of the many caveats involved when moving tables from Access to a back end, many people opt to design the tables directly on the back end. If you do design your tables in Access, you can export them to the back end and then link them to your local database, or you can use the Upsizing Wizard (covered later in the chapter) to greatly facilitate this process. Regardless of the method that you choose, as you export your tables to the database server, you need to be aware of the issues covered in the following sections.
NOTE
If you are updating to a SQL Server database, the upsizing wizards included as part of Microsoft Access 2000 and Microsoft Access 2002 handle most of the concerns involving upsizing.
Indexes
When exporting a table to a server without the use of the Upsizing Wizard, no indexes are created. You need to re-create all indexes on the back-end database server. If your database server is running Microsoft SQL Server, you can use the Access Upsizing Wizard for Access 2000 or Access 2002. These wizards create indexes for server tables in the place where the indexes exist in your Access tables.
AutoNumber Fields
AutoNumber fields are exported as Long integers. Because some database servers (other than Microsoft SQL Server) do not support autonumbering, you have to create an insert trigger on the server that provides the next key value. You also can achieve autonumbering by using form-level events, but this is not desirable. If other applications access the data, the numbering is not enforced. If you are upsizing to Microsoft SQL Server, the Upsizing Wizard for Access 2000 and Access 2002 converts all AutoNumber fields to Identity fields.
Default Values
Default values are not automatically moved to the server, even if the server supports them. You can set up default values directly on the server, but these values do not automatically appear when the user adds new records to the table unless the record is saved without data being added to the field containing the default value. As with autonumbering, you can implement default values at the form level, with the same drawbacks. If you use the Upsizing Wizard for Access 2000 or Access 2002 to move the data to Microsoft SQL Server, default values are exported to your server database.
Validation Rules
Validation rules are not exported to the server. They must be re-created using triggers on the server. "No Access-defined" error messages are displayed when a server validation rule is violated. You should code your application to provide the appropriate error messages. You also can perform validation rules at the form level, but they are not enforced if the data is accessed by other means. The upsizing wizards for Access 2000 and Access 2002 export validation rules to the SQL Server database.
Relationships
Relationships need to be enforced using server-based triggers. Access's default error messages do not appear when the data violates referential integrity rules. You need to respond to and code for these error messages in your application. You can enforce relationships at the form level, but, as with other form-level validations, this method of validation does not adequately protect your data. If you use the Upsizing Wizard for Access 2000 or Access 2002 to move the data to Microsoft SQL Server, all relationships and referential integrity that you have set up in your Access database are set up within the server database.
Security
Security features that you have set up in Access do not carry forward to the server. You need to re-establish table security on the server. After security is set up on the server, Access is unaware that the security exists until the Access application attempts to violate the server's security. Then error codes are returned to the application. You must handle these errors by using code and displaying the appropriate error message to users.
Table and Field Names
Servers often have much more stringent rules than Access does regarding the naming of fields. When you export a table, all characters that are not alphanumeric are converted to underscores. Most back ends do not allow spaces in field names. Furthermore, many back ends limit the length of object names to 30 characters or fewer. If you already have created queries, forms, reports, macros, and modules that use spaces and very long field and table names, these database objects might become unusable when you move your tables to a back-end database server.
Reserved Words
Most back ends have many reserved words. It is important to be aware of the reserved words of your specific back end. It is quite shocking when you upsize a table to find that field names you have been using are reserved words on your database server. If this is the case, you need to rename all the fields in which a conflict occurs. Again, this means modifying all the queries, forms, reports, macros, and modules that reference the original field names.
Case Sensitivity
Many back-end databases are case sensitive. If this is the case with your back end, you might find that your queries and application code don't process as expected. Queries or code that refer to the field or table name by using the wrong case are not recognized by the back-end database and do not process correctly.
Visual Basic Code
Certain properties and methods that work on Access tables might not work on remote tables. This might necessitate some coding changes after you export your tables.