On opening the Catalog it does not copy the entire Catalog into memory. This would suggest that each user that opened and modified a catalog would overwrite his entire version each time he saved, thus making shared catalogs an impossibility.
This was suggested by COGNOS's recommendation for each user to have his individual version of the catalog.
What DM does:
DM reads the entire object tree at start up. If you change the name of an object in one session but not in another when you try to access you get
1. ERRORDM-CAT-0910 Export failed; JobStream 'LoadOrgExtractsToGroupTable' does not exist.--------------------------------------------------------------------------------
2. ERRORDM-CAT-0406 JobStream 'LoadOrgExtractsToGroupTable' cannot be validated.
This is a fatal error that takes you out of DM and hence explains Cognos' recommendation of individual versions of the catalog.
DM copies the catalog object by object into memory as they are accessed. When you 'Save' you write the altered versions of objects back to the database. I dont know if DM reads unaltered objects back from the database each time or whether it caches them.
What DM should do to allow multi user access to the same Catalog
DM should place a date modified at the root of the catalog tree and this should cause the tree to refresh if a version has an older version. All objects should be referred to by an internal code to prevent a name change causing confusion.
DM should never cache objects unless they are altered. When they are altered they should be locked on the database and other users should be able to view the object with a warning that they cannot alter it since someone else is altering it.
In the word of the Meerkat - ees simples for Cognos to sort out this major bugbear and misunderstood facet of the product.
No comments:
Post a Comment