Each time you define or change domain, table, and column attribute values in USoft Definer that affect physical RDBMS tables, you can have USoft (re)generate the corresponding database tables in the RDBMS along with their indexes.
You can (re)generate instantly or you can write a script that contains the instructions the RDBMS needs for (re)generating tables and indexes. These instructions are SQL DDL statements, for example, CREATE TABLE and CREATE INDEX statements.
When (re)generating tables, USoft automatically performs a difference analysis with the existing RDBMS data structure. Instructions for (re)generation are only issued for tables, columns and indexes that have actually changed.
(Re)generating tables is a manual action. USoft does not automatically synchronise the data structure in the RDBMS with new or changed USoft Definer specifications.
Transition method: OLD_ tables
In most cases, USoft will decide to transition to a changed data structure by first renaming the existing RDBMS table (if any) to its equivalent with the prefix OLD_, then creating the new table, and then transferring existing data to the new table. You can inspect this by letting USoft generate a script, rather than execute the table generation instantly:
RENAME TABLE product TO old_product
CREATE TABLE product ( ... )
INSERT INTO product SELECT ... FROM old_product
|
In some cases USoft will implement a transition by issuing an ALTER TABLE statement. If you prepare table generation in USoft Delivery Manager, you can determine yourself for each table which of the two methods is applied.
Where to activate table generation
You can activate table generation in multiple places in the USoft tool set.
In Development, best practice is to instantly re-generate an RDBMS table each time you have made a series of changes that affect it. Do this by pressing the Create button in the Tables window for the table. The Create button does not give you the option to create a script.
|
You can run the Create Physical Tables wizard to (re)generate RDBMS tables after changes have occurred that affect these tables. This way, you can choose to (re)generate only tables that you specifically select; to have all new or changed tables (re)generated; or to have all tables in the data model (re)generated.
You can choose to execute immediately or write the RDBMS instructions to a script. The script option is useful for inspecting the operations that will take place before actually executing them. A script may also be carried to a different (non-Development) environment to make the same amendments to the RDBMS table structure there, but this is only guaranteed to work if you are sure that the existing situation is the same as in Development.
Start the Create Physical Tables wizard by choosing Tools, Create Physical Tables from the USoft Definer menu.
|
You can (re)generate the RDBMS data structure of your application by running the Create Tables option in a USoft Binder item for the application. Do this by right-clicking on the USoft Binder item and choosing Create Tables from the context menu.
This option is useful when you have carried a .CON flatfile of your changed USoft Definer definitions to a different environment and you have access to the application in that environment through a USoft Binder file.
When (re)generating tables in this way, you can choose to drop existing tables. Do this by setting Drop Existing Tables = Yes in the dialog. CAUTION: This will cause all existing application data (if any) to be cleared.
|
You can (re)generate tables using various USoft Benchmark routines for data management. This is suitable only for test environments, where existing data do not matter because they are re-initialised. Run USoft Benchmark in the context of your application, then press the Data button in the Benchmark Toolkit window. See USoft Benchmark Guide for details.
|
You can have a release script for (re)generating tables created automatically by USoft Delivery Manager. Such a script is based on differences with the RDBMS data structure in the previous version or previous release of your application. A release script can be prepared in Development and then run successfully in Test, Acceptance, Production and other environments. See UDeliver Delivery Manager Guide for details.
|
See also
Tables
Indexes
|