Cognos 8.0 Report Writer

[DataGirl67]

Hi -- I'm looking through the forum and I haven't seen this question. I'm very new to Cognos -- being "trained" just this week. So, far in Report Writer, I do not see any way to write my own SQL code. I can see how to enter a WHERE clause, but no actually sit down and write the query.

Is there a way to do this? It'll kill me if my report writing abilities are reduced to drag and drop!

 

[blom0344]

The point is to have an optimum metadata layer, so writing SQL is reduced to the utmost urgent cases.
In Report Studio you can drag an SQL (instead of a query) object into the report and roll your own SQL.
Make sure to get the proper combination of used syntax and the properties.

Are you aware that developing reports should be done against a package published with Framework manager.
Take some time to pick up best practices before handcoding your reports!

Ties Blom

 

[DataGirl67]

Thanks for the response. What we have is hundreds of Crystal Reports for various customers that we need to convert over to Cognos, as well as create ad hoc reports. Some of our reports are quite complex and pull from quite a lot of tables.

I am aware that the developing of reports need to be against a package, but I'm being told that most of our reports should run off the same package.

Since I'm not familar with Cognos, I don't know if this is a good thing or not.

If I understand you, the complex SQL I've done in the past should be part of the package, correct?

 

[blom0344]

The idea with Cognos 8 is to model a framework (comparabel with a BO universe) on your physical datasource(s)
That way Cognos is able to come up with the SQL for reports.
A package can contain metadata from different sources, but one report can onlt adress one package at the time.
The complexity is not with number of tables that you address in an SQL query. The whole point is to model your framework to starschema's ,so Cognos can build complex multi-fact, multi-grain queries.

Cognos modelling will cover most SQL techniques, though there is a clear limit. Recursive techniques are beyond the model as are correlated subqueries (though you can still define them as SQL objects in the framework).

My advice would be to take one step back and look at developing a robust framework instead of going for the SQL approach. That way you can draw advantage from the many assets of framework design and you have a good basis for building new (ad-hoc) reports.


Ties Blom

 

[AngelaCognos]

Yes, the advice to take a step back is ideal. In fact, I would say do not proceed without training in both report writing AND modelling. Of course, it doesn't have to be the same person, but the modelling is such a key to your success that I would estimate you could face project failure without clear modelling practices.