Column Origin

[ThunderForest]

I am new to a company and have good experience in report writers; however, this is my first exposure to Cognos, which is v7.1.339. One of the biggest complaints I am receiving is that when looking at a report design, you cannot tell what table a column is from, e.g., there is no dot notation, table1.columnA. Instead, it's just columnA. What I'm trying to say is if there is a columnA in several other tables that are joined in the report, and columnA is in your filter, how can you tell what table it's from? Has this changed in a later version?

Getting answers before I'm asked.
Providing answers if I can.

 

[blom0344]

One way is to check the SQL generated. The filter condition is in the WHERE clause..

Ties Blom

 

[yphilogene]

It has not changed in Cognos 8. The Framework Manager model still ask for a "Business Name". I don't think it is normal to have the name of the table within the name of the column. It's more a technical need that a business need.

However, I understand your point. What may interest you is the management of multilanguage in Cognos 8. In a model, every column (query item) is identified by its path. For example:

[Business View].[Time].[Yr]

If you build a report that uses the query item [Year], then you rename this query item in the model (for example, renaming it [Year] for presentation purpose), your report won't be valid anymore because you'll have to change the expression of the item in the report.

That's why, a development method could be to develop reports in a langage in which query items won't be renamed. In this language, the query item "Year" could have the physical path for example:

[Business View].[TAB001_TIME].[TAB001_YEAR]

Then, in your model, you use another language to translate the labels of the query items in a business language. Therefore, developpers (who must develop in the "development report language") can see explicitly where the data come from, and the end-user (who is connected to the portal on the "business language") see the model in an understandable business-oriented language.

 

[yphilogene]

To sum up:

1) Implement a model in a "development language" (where columns contains the name of the table)

2) Translate the model in a "business language"

3) Use the "development language" to develop reports

4) Use the "business language" to access understandable business-oriented labels in your model.

 

[ThunderForest]

Thanks yphilogene. Good idea for the future. Also, Ties, I didn't know you could get the SQL until "after" the report generated. That will help for now. Thanks also.

Getting answers before I'm asked.
Providing answers if I can.