Progress
Programming
Handbook
CRC Versus Time Stamp Validation
The main advantage of using CRC validation is that you can run the same r-code against different databases as long as the databases have sufficiently similar schemas. This allows you to deploy code and database updates while avoiding either of the following effects:
Depending on the schema changes, the user still might have to dump and reload some data, but you can always supply r-code for their updated database.
Database Changes that Affect Time Stamps
You must recompile procedures that reference a database table in which you have made any of the following changes:
- Deleted the table
- Changed the table name
- Changed the database language or authorization key
- Added or deleted a field in the table
- Changed the name or order of a field
- Added or deleted an index
- Modified an index by changing its name, uniqueness, field components, collation order, or the abbreviation option
Although you do not have to recompile procedures when you make other schema changes, such changes do not apply to procedures that you do not recompile. For example, changes to the following features appear only when you recompile:
Database Changes that Affect CRCs
You must recompile procedures using CRC-based deployment for the same schema changes that change a time stamp. In addition, you must recompile procedures that reference a database table in which you have made these changes to a field:
Table A–2 lists all the metaschema fields involved in database CRC calculation.
NOTE: The order in which indexes are defined has no effect on database CRCs.Time Stamp-based Deployment
Using time stamp validation, if you deploy r-code, you must compile the procedures against a schema-updated version of the user’s database and send both the r-code and the new database to the user. Otherwise, the r-code cannot run, and you must deploy source code for the user to compile along with new database definitions to update their schema.
CRC-based Deployment
Using CRC validation, if you deploy r-code, you only have to compile the procedures against a database with the same basic structure as the end-user database. It does not matter when or where the database was created. If you make schema changes to an existing database, you can distribute the newly compiled r-code to end users, along with a data definition files to install the schema changes.
The flexibility of CRC-based deployment makes it easier to distribute a new version of an existing application. To deploy an application update based on CRC validation, follow these steps:
- Install a copy of the production database from the target site in your development environment.
- Create an incremental data definition file that captures the difference between your development database and the production copy. For information about creating an incremental data definition file, see the Progress Database Administration Guide and Reference.
- Apply the incremental data definition file to your copy of the production database.
- Recompile all procedures affected by the schema changes against your copy of the production database.
- Apply the incremental data definition file to the original production database (on site). The CRC for the original production database should now be identical to the production copy, but probably not identical to your development database.
- Distribute the new r-code files (from Step 4) to the updated production site.
The steps for CRC-based deployment are essentially the same as those for time stamp-based deployment, but you gain these advantages:
Differences in R-code Access Authorization
One possible drawback of using CRC validation is that anyone having a Progress development environment can create a counterfeit database (a database with the same structure as your database). The user can then write a program, compile it, and run it against your database. Using time stamp validation prevents this because the time stamps in the counterfeit code do not match those in your database.
However, you can also combine CRC validation with additional security to prevent unauthorized r-code access. The DBAUTHKEY option of the PROUTIL utility allows you to set an authorization key for your database. When you compile your source code, Progress includes the value of this authorization key in your r-code. You can also use the RCODEKEY option of PROUTIL to insert the authorization key in existing r-code. Any r-code that does not include the correct authorization key cannot run against your database. For more information about using PROUTIL to create and set database authorization keys, see the Progress Database Administration Guide and Reference.
CRC and Time Stamp Availability
During compilation, Progress always inserts both database time stamps and CRCs in the r-code. If a database is not connected with the Time Stamp (–tstamp) parameter during procedure compilation, Progress turns on a bit in the r-code. This bit tells the run-time interpreter to check the CRC if the time stamp check fails.
NOTE: The Time Stamp (–tstamp) parameter is obsolete, and is supported only for backward compatibility.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |