Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Column Origin

Status
Not open for further replies.

ThunderForest

IS-IT--Management
Mar 3, 2003
189
US
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.
 
One way is to check the SQL generated. The filter condition is in the WHERE clause..

Ties Blom

 
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.
 
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.
 
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.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top