WID File Size

[dbomrrsm]

The project I am working on has some webi 6.5.1 reports that calculate year to date figures (daily and weekly) compared to the same period last year.

The reports are scheduled to run overnight so the time it takes to run them isnt a problem at the moment.

However, we are currently at week 16 (out of 52 - for any of you that dont know how many weeks are in a year ;-) ) and the size of the WID file for some reports is already 140 megabites in size.

These reports have got to run against low level aggregate tables because there are objects in the report that are incompatible with the higher level aggregate tables so we cant change this and the reports are just going to keep growing week on week.

By my fag packet calculations the 140 mb wid file is going to be 455 mb by the end of the year and I am concerned that this sort of sized file will cause difficulties for Webi.

The current saved version takes about 40 seconds to open !!

So to my question:

Is there a size beyond which BO can not handle a WID file.

TIA



[blue]DBomrrsm[/blue]

[blue]Software code, like laws and sausages, should never be examined in production[/blue][black] - [/black][purple]Edward Tenner[/purple]

 

[skrandel]

No size limit, but you're already at a problem point.

Personally, I think you'r going about this wrong. IF this is such an important report, why not have an ETL process that puts the data into a table.

You can't realistically have the amount of detail you're talking about in a BO report.

Steve Krandel
Symantec

 

[dbomrrsm]

Thanks Steve

The problem we have got is in the schema design - there are 6 levels of aggregate tables but the highest 4 of these do not have keys that can link to some attribute information so the reports have to run at the 5th level so the data brought back is quite substantial.

I am looking at ways of establishing a link between the higher level aggregate tables through the dimension and on to the attribute table beacuse at the moment few reports can use the aggregate tables.

[blue]DBomrrsm[/blue]

[blue]Software code, like laws and sausages, should never be examined in production[/blue][black] - [/black][purple]Edward Tenner[/purple]

 

[AndreasSchneider]

It looks to me that your measures are not using SQL aggregate functions and instead you are bringing back every detail row from the database into your report and calculate your summary data at the rpeort level, am I correct?

Remember that measures should (usually) always use some SQL aggregate function or they should not be measures in the first place.