by
JADE Support >> Fri, 13 Jul 2001 4:24:40 GMT
Theo,
We recently dealt with a similar problem for another customer and since you've now also asked I will create an FAQ on the JADE Web Site as well as answering here.
The .mul schema load process will always try to ensure that it defers any required reorg(s) until the completion of all the .scm file loads. If your ...mul file only contains .scm files, then any required reorg will always be deferred until the completion of the last .scm file load. However, if you have .ddb files included in the .mul load, and a previous .scm file load has marked either Global or a subclassed control for reorg, the .mul load process must reorg the database prior to loading the .ddb file.
Therefore, if we defer the loading of the .ddb files until after all the ...scm files have been loaded then any reorg due to Global or subclassed controls being marked for reorg will only be actioned on the first .ddb file that is loaded and will reorg all the structural changes made by all the ...scm files that were loaded previously. If Global was not marked for reorg, nor any subclassed controls, then the reorg will not occur until the end of the .mul load.
There is, however, a further complication in the current release of JADE when performing a .mul load. You cannot have a line in the .mul file containing only a .ddb file name as the .mul load process uses the context of the .scm file on the same line in the .mul file to determine which schema this .ddb file is to be loaded against. Therefore in order to defer the loading of the .ddb files until all the structural change .scm files have been made, we need a "dummy" .scm file for each .ddb file. This dummy file should be a partial definition of the schema and the easiest way to create this file is to perform a selective extract of the schema and not select any classes to be extracted.
As an example the following .mul file will load three .scm files, then load a "dummy" file for each of these Schemas in order to load the relevant .ddb file.
TopSchema.scm
NextSchema.scm
AnotherSchema.scm
TopSchema_dummy.scm TopSchema.ddb
NextSchema_dummy.scm NextSchema.ddb
AnotherSchema_dummy.scm AnotherSchema.ddb
I hope that helps explain the reason for the extra reorgs, a way to ensure you only have 1 reorg and I will also open an NFS suggesting it would be good if the multiple schema load process could somehow detect this situation and automatically handle it.
Thanks,
JADE Support.
jadesupport@discoverjade.com
news.jadeworld.com