Compare Qlikview with BO is like to compare Orange with Banana, they both are fruits but they are

different, in shape, health properties and so on. Its very important to define what your users need in terms of data Analisys. Depending on your answers, the choice could be Qlikview or BO. You choose Qlikview if you want: - Rapid Time to Value. - No need to pre build a Datawarehouse. If you dont have one, you will not need it. - Querys with subsecond responses, achieved with In-Memory Data. - Enable users to explore data from less detail (more agregated data) to transaction level (detailed data). - High interactive Dashboards. - One Single Product for ETL, Development and End User Analysis. - Empower Users with the hability to create their own analysis with their own data. You choose BO if: - You want to expend lot of time and money building a datawarehouse and that is not a problem in your project. Connecting BO directly to your production database could seriouly impact performance. - Also you have a dedicated DBA to manage the datawarehouse. - Your users need to create static Reports, not dynamic Analysis. - If you already a SAP customer, maybe they gave you the software for free. But you still need to pay a lot of consulting.

============
I suppose that depends on what you mean by ad-hoc reporting. QlikView loads all of the data into memory according to a script. Generally speaking, your users then interact with the data in the ways you have set up. You can set up very dynamic charts if desired. What QlikView doesn't let your users do is actually CHANGE what data is loaded into memory. They can't go and run SQL against the live databases (well, not usually). They're always interacting with a copy of the data. The load script can use SQL against the live databases, but this is under developer control, not user control. On the other hand, if you want your users to be able to view any field from the database, feel free to load every single field in. I don't do that personally - I want to exercise more control over what my users see and what they don't see, plus our real databases are fairly generic and cryptic and not really understandable by users. I don't believe our own users do this, but the users CAN create completely new charts on the fly, and can share these with other users. The difficulty is that except for the simplest possible charts, this is probably beyond most users. Well, it's not REALLY that hard. It's like getting good at Excel, and not really much more complicated than that, and in some ways simpler. But our users don't bother. They just come to the systems department when they want a new field on a chart, for instance. Our turnaround time for simple changes is very fast, so it isn't much of an issue. I can see how if we were a lot slower at getting them their data, they might want to learn how to create their own charts.

(Edit: Found out today that at least one user is using at least one user-defined chart, because I accidentally broke it when I removed a bunch of "unused" fields from the in-memory data model. Oops!)

==================== http://community.qlikview.com/thread/23448 ======================= http://2y.pinlift.com/5i5.php?u=T2k4dlluVnphVzVsYzNOcGJuUmxiR3hwWjJWdVkyVmtkeTVpYkc 5bmMzQnZkQzVqYjIwdk1qQXdPQzh3Tmk5eGJHbHJkbWxsZHkxMmN5MXZkR2hsY25NdWFIUnRi QT09&b=13

7. Integration with Microsoft Office tools- Qlikview just exports the data into an excel file or exports a report object to a png file or using OCX you can do something to make it work with MS office tools(I never tried this). 12. SQL Generation- If you want to see the SQL generated behind a query, you can not see that in Qlikview whereas other tools like OBIEE, Cognos, BO and Essbase allows you to see the SQL/MDX generated for a query. This feature may not be relevant to business users but for developers this helps a lot in their day to day activities like debugging or data validation.