Kbase P21078: RTB not deploying all data required for Dynamics application
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/02/2010 |
|
Status: Verified
SYMPTOM(s):
Roundtable not deploying all data required for Dynamics application
Application error messages are not deployed
Menu Items are not deployed
Runtime attributes are not deployed
Master class attributes are not deployed
Dynamics 2.0A01
Dynamics 2.0A02
FACT(s) (Environment):
Dynamics 2.0A
Dynamics 2.1A
Roundtable 9.X
Windows
CAUSE:
Bug# OE00087652
FIX:
There is no fully automated way of doing this at present.
It is possible to get this semi-automated by doing the following:
1) Create a set of custom product modules in RTB for handling custom variants of the existing dataset in the RTB repository. (There are .ado files for all of the standard datasets - which contain all of the standard Dynamics menus, error messages, attributes etc.)
2) Make sure the product modules are added to the workspace sources of the workspace.
3)The standard datasets are stored in the product module db-icfdbdump - so I would suggest something like xxxdb-icfdbdump - possibly pointing into the same directory as the original module src/icf/db/icf/dump).
4) Create a set of "custom" datasets to contain ALL of the data from an updated repository (so for menu items this would be all of the standard Dynamics menus as well as the application menus, modified menus etc). Make sure the name of the datasets are prefixed with something to make them different from the standard datasets (this has to be done manually for each dataset from the DataSet Export tool).
For example, for menu items, the standard dataset is gsmmi.ado. This could be called <site_number><product_code>_gsmmi.ado, where <site_number> is the Roundtable site number and ><product_code> is a short code for the product being developed. e.g. 001at_gsmmi.ado.
5) Register the custom datasets in RTB with Module Load or File | New Object. As we do not have a generic Object Type for DataSets, it is important that the datasets are registered under the Code Subtype of LSmartObject - which is a single part object type with a .ado file extension. Ideally, we should have a Code Subtype of DataSet for this.
6) When the new objects are checked in, make sure that the functionality to automatically export data from the ICFDB repository is NOT used - as this will overwrite the dataset with "empty dataset" content.
7) When these datasets are then imported to another workspace, the .ado extension will result in the data being loaded into the target ICFDB database.
8) Whenever changes are made to the data being managed in this way, the objects must be checked out, and the data dumped - manually using the DataSet export tool in the same way as when they were created.