لطفا منتظر باشید ...
Upsizing: What to Worry About
Suppose that your database is using Microsoft Access as both the front end and 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. The Access tables already have been created and even contain volumes of data. In this scenario, it might make sense to upsize.Because all the tables have been designed as Access tables, you must upsize them 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 2003 Server, and Windows NT Server, or as a Novell NetWare NLM.Another reason why you might decide to upsize tables 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 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.NOTEIf you are updating to a SQL Server database, most of the concerns regarding upsizing are handled by the Upsizing Wizards included as part of Microsoft Access 2000 and above.
Indexes
When exporting a table to a server, no indexes are created. All indexes need to be re-created on the back-end database server. If your database server is running Microsoft SQL Server, you can use the Access 2003 Upsizing Wizard. This wizard will 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 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. The numbering will not be enforced if other applications access the data. If you are upsizing to Microsoft SQL Server, the Upsizing Wizard for Access 2003 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 new records are added 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 2003 to move the data to Microsoft SQL Server, the wizard exports default values 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. Your application should be coded 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. If you use the Upsizing Wizard for Access 2003 to move the data to Microsoft SQL Server, validation rules are exported to the server database.
Relationships
Relationships need to be enforced using server-based triggers. Access's default error messages do not appear when referential integrity is violated. 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 2003 to move the data to Microsoft SQL Server, the wizard sets up all relationships and referential integrity that you have set up in your Access database 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 you set up security on the server, Access is unaware that the security exists until the Access application attempts to violate the server's security. Then, the server returns error codes 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, most 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. Reserved words are words used by the back end in its own operations. It is important to be aware of the reserved words of your specific back end. It is quite shocking when you upsize a table and 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. Once 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.
Properties
Most properties cannot be modified on remote tables. Any properties that can be modified are lost upon export, so you need to set them up again when you export the table.
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.
