Catalog - Internal numbers (dangers)

[w860098]

We are using a 'corporate' version of the data warehouse but need to add additional 'local' tables and columns to the database structure. This will then necessitate applying additions/modifications to the issued catalog. [We are using specific prefixes to ensure there is no clash of names]

I have now been warned by the central development team that I will encounter problems in the future, i.e. when they issue an upgrade to their system and I add back in the modifications I have made locally.

I am told this is because Cognos issues internal ids for the items defined within the catalog and these are used in Impromptu, etc. to identify the specific data items referenced within the report(s).

When changes are applied to the catalog, there is a risk that particular internal ids will now point to a different item in the database.

Can anyone clarify if I really do have a (potential) problem. If so, what are the recommendations of how to minimise the affect of this difficulty.

 

[CognosProfessional]

Are your tables going to be on the network and in .ims format? Are the users accessing the 1 catalog for all? If so, then you should have no problems.
The problems arise when there are many catalogs, and they are copied to users hard drives.

CP

 

[w860098]

To clarify further - the 'corporate' version is designed and built centrally, in Germany (as a common solution which is then issued to the individual countries).

Thus we install a 'free-standing' system in the UK and the changes we apply are only relevant to our particular installation. [In particular, we have the Oracle database installed on one server, with the Cognos applications running on another server]

I therefore assume we will encounter the problems involved with 'many catalogs'.

If possible, could you provide some advise to help us minimise the difficulties we might encounter when we have to 'transfer' our modifications to any re-issued versions of the data warehouse system.

 

[punitagnihotri]

Hi,

As per my understanding of your query.

to minimize the amount of the work required in case of changein the DWH, you must have knowledge about the mapping of the database field and the logical name used in the Catalog for that field.

If there is change in say one of the table then you have to remove the table from the catalog and add it again.
Then make sure that when you again add the field of the changed folder make sure that it is added in the same folder with the same name as before.

I hope it will help.

 

[Pommie]

What will happen to any reports written using the 'originally' changed catalog if tables are removed and re-added to pick up definition changes. Will they still work correctly if the underlying field names haven't changed? or do they use internally generated field id's?

 

[w860098]

To help clarify the situation I am trying to cope with, I have included below two sets of detail which show what we are trying to achieve.

The first of these represents the 'current' state of the database and catalog where, hypothetically, a number of tables and columns (together with associated catalog folder and item names) exist - those with prefix DC having been defined in the system issued from our central development team, whereas those prefixed UK have been added by us locally.

A) ORIGINAL STRUCTURE

Table Column Folder Catalog Item Comment
DCt1 DCt1c1 DCf1 DCf1i1
DCt1 DCt1c2 DCf1 DCf1i2
DCt1 DCt1c3 DCf1 DCf1i3
DCt1 DCt1c4 DCf1 DCf1i4
DCt1 DCt1c5 DCf1 DCf1i5
DCt2 DCt2c1 DCf2 DCf2i1
DCt2 DCt2c2 DCf2 DCf2i2
DCt2 DCt2c3 DCf2 DCf2i3
DCt3 DCt3c1 DCf3 DCf3i1
DCt3 DCt3c2 DCf3 DCf3i2
DCt3 DCt3c3 DCf3 DCf3i3
DCt3 DCt3c4 DCf3 DCf3i4
UKt1 UKt1c1 UKf1 UKf1i1
UKt1 UKt1c2 UKf1 UKf1i2
UKt2 UKt1c1 UKf2 UKf2i1
UKt2 UKt1c2 UKf2 UKf2i2
UKt2 UKt1c3 UKf2 UKf2i3
UKt2 UKt1c4 UKf2 UKf2i4
UKt2 UKt1c5 UKf2 UKf2i5

The second list shows the situation when the central project team have re-issued the system, incorporating certain changes to the structure - these might involve the inclusion of additional column(s) into an existing table and/or the provision of a new table with associated columns. This of course means that our particular (original) local extensions have now had their position disrupted within the overall definition of the structure.


B) UPDATED STRUCTURE

Table Column Folder Catalog Item Comment
DCt1 DCt1c1 DCf1 DCf1i1
DCt1 DCt1c2 DCf1 DCf1i2
DCt1 DCt1c3 DCf1 DCf1i3
DCt1 DCt1c4 DCf1 DCf1i4
DCt1 DCt1c5 DCf1 DCf1i5
DCtx DCtxc1 DCfx DCfxi1 New table added
DCtx DCtxc2 DCfx DCfxi2
DCt2 DCt2c1 DCf2 DCf2i1
DCt2 DCt2c2 DCf2 DCf2i2
DCt2 DCt2c3 DCf2 DCf2i3
DCt3 DCt3c1 DCf3 DCf3i1
DCt3 DCt3cx DCf3 DCf3ix New item in existing table
DCt3 DCt3c2 DCf3 DCf3i2
DCt3 DCt3c3 DCf3 DCf3i3
DCt3 DCt3c4 DCf3 DCf3i4
UKt1 UKt1c1 UKf1 UKf1i1
UKt1 UKt1c2 UKf1 UKf1i2
UKt2 UKt1c1 UKf2 UKf2i1
UKt2 UKt1c2 UKf2 UKf2i2
UKt2 UKt1c3 UKf2 UKf2i3
UKt2 UKt1c4 UKf2 UKf2i4
UKt2 UKt1c5 UKf2 UKf2i5

This detail has been extracted from a spreadsheet; so if we imagine that the worksheet row ids equate to the Cognos Internal ID numbers, then of course a number of the data items will acquire a different number when the system is upgraded.

The question is "Would these changes have any affect upon existing reports ?"

If so, what tips can be provided to minimise the affect of these changes ?