Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Updating Database Schemes (Deployment)
See Also
Programmer's Guide > OpenAccess ORM Classic (Old API) > Deploying Telerik OpenAccess ORM > Updating Database Schemes (Deployment)

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

Telerik OpenAccess ORM can derive the SQL database schema out of your persistent application classes. When you modify your persistent class (example: adding a new field, then the new field results in a new column) database schema changes are applied. The Telerik OpenAccess ORM integration in the Visual Studio performs this step during build. While doing so, a text file with the necessary SQL statements is generated and put in the bin directory with a name like "Schema_Migration_mssql_2007-02-16_07_30_57.sql". Every time the database schema is altered, the corresponding change is recorded in such a file with a unique time stamp.

Other (customer) databases can also be modified with the help of the provided VSchema command line tool. This tool can be used at the customer side for executing the SQL statements from such a file (refer to Using VSchema for more information).

Since multiple changes to a database in the course of your development would result in multiple .sql files, you might want to concatenate them into one big .sql script. You might also want to migrate or initialize data in this step, something Telerik OpenAccess ORM cannot handle on it's own, as it is application dependant. For that you can modify the .sql script according to your needs.

One way to simplify the task of concatenating all the changes is to use an empty database that conforms to the last shipped version of your application. During the build with your newest version, Telerik OpenAccess ORM will notice all the differences between the "old" database and your application classes. This will result in a complete .sql script containing all the necessary schema modifications. Again, you might want to modify this script to perform data initialization/migration on the customer's side.

See Also